FAQ

On Mon, Apr 16, 2012 at 4:07 PM, Ken Barber wrote:

A pm2rpm tool perhaps Todd? :-).

Something like pm2rpm would work, but we need to have a least one standard
path for Puppet modules. I guess we can count on /etc/puppet/modules or
/usr/share/puppet/modules being part of the default module path.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Ashley Penney at Apr 17, 2012 at 1:15 am
    This is kind of an argument against moving these things out of the core in
    the first place in my opinion. The fact that you can now have multiple
    versions of the nagios provider is just worse than having a single copy.
    Before at least I could update to 2.7.x and be assured all my providers
    were at the same version, now I have to deal with all the module updates
    (which only grows as time goes on) and constantly deal with checking them
    into git, managing them, testing them with various versions of the client.

    I get why you're doing this but as an end user this is just causing me more
    work and making me do more testing and a lot more management. At least
    before I could rely on having a broad set of core resources. Now we're
    going in the opposite direction.

    Maybe I'm just a grouchy old sysadmin but now I can't just rely on
    yum.puppetlabs.com to provide my resources and that means time out of my
    day to update them and push them into git. In the workflow we've
    instigated at work I cannot just throw in an update and push it - I have to
    create branches, run tests, open tickets. With things provided by puppet's
    core I just have to get approval to update the client in one easy push.

    Maybe I'll just make /etc/puppet/modules/ for modules imported directly
    from the forge (and unedited in any way) and instigate easier rules around
    updating these.

    Sorry if this turned into a bit of a "GET OFF MY LAWN" post.

    On Mon, Apr 16, 2012 at 8:45 PM, Michael Stahnke wrote:
    On Mon, Apr 16, 2012 at 11:36 AM, Todd Zullinger wrote:
    Michael Stahnke wrote:
    For the next major Puppet version, code-named Telly, we have some
    changes
    coming. This is the first in a series of emails around these changes
    and
    may require some input from the community.

    For Telly, the nagios types will be moved into a module. This allows
    them
    to be iterated on in isolation from the rest of Puppet's core release
    cycle
    and process. In the future we have plans to move several other types
    into
    modules that can be individually maintained, improved, tested and used.

    The module for Nagios will be available on the Forge.

    The upgrade path is the thing we need some feedback about. The basic
    steps to upgrade would be to setup a Telly master, and then install the
    Nagios module via the Puppet Module Tool, which ships integrated with
    2.7.13+ and Telly.

    Is it possible to package these modules for distros? In the past, we've had
    a few requests to do this for third-party modules but we didn't do this
    because there wasn't really any standard for it. With puppet module tool
    being integrated now, perhaps that's something that can be reconsidered.

    I'm thinking that for folks using rpm, they'd rather see an update that
    pulls in the same fucntionality as they had before. And even for new
    installs, I'd personally prefer to install these things via rpm. If I
    wanted to use a secondary package management system, I could use gems or
    eggs or CPAN, but I don't. ;)
    Todd, welcome and I feel your pain. Trust me, I pushed every way I
    could to use native packages as our module deliver mechanism. However
    we have some odd requirements that make things not work as well with
    RPM (or deb, or gems). Basically we need a mechanism to allow
    multiple versions installed into separate environments (paths on
    disk). That sort of ruled out traditional packaging systems, without
    doing some installation and symlink-selection magic. Even then, there
    were some issues.

    Something like pm2rpm and pm2deb is very likely something we'll need
    to make the lives of Puppet Users happy. It should be fairly simple
    and we'll want to be sure that the default module path is something
    that is FHS compliant.

    We'll also want to work with Jordan and see if we can get packaging
    Puppet Modules (in this format) as an option with FPM. I think FPM
    already does some Puppet Module stuff, so it may not need any real
    updates.

    Mike


    I think it's good to split out these things, as it would allow us to
    properly add a nagios dep to the hypothetical puppet-module-nagios package.
    --
    Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    I am free of all prejudice. I hate everyone equally.
    -- W. C. Fields
    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Tim Mooney at Apr 17, 2012 at 5:35 pm

    In regard to: Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types...:

    Todd, welcome and I feel your pain. Trust me, I pushed every way I
    could to use native packages as our module deliver mechanism. However
    we have some odd requirements that make things not work as well with
    RPM (or deb, or gems). Basically we need a mechanism to allow
    multiple versions installed into separate environments (paths on
    disk).
    You make a compelling argument for why this doesn't map well to native
    packaging tools. While it is possible to have multiple copies of an RPM
    installed simultaneously, it would be a kludge in this case.
    Something like pm2rpm and pm2deb is very likely something we'll need
    to make the lives of Puppet Users happy.
    Now that puppet has drug me into the ruby world, I've started down the
    path of RPM packaging of gems. gem2rpm helped me get started. Having
    something that works very similar to that would be a big help to those
    that are experienced with ruby & gems.

    Whatever you choose, though, there needs to be a way for admins to query
    a client and find out

    - what puppet modules are installed
    - where each instance of the module is installed
    - what "version" is present in each instance

    Tim
    --
    Tim Mooney Tim.Mooney@ndsu.edu
    Enterprise Computing & Infrastructure 701-231-1076 (Voice)
    Room 242-J6, IACC Building 701-231-8541 (Fax)
    North Dakota State University, Fargo, ND 58105-5164

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Nigel Kersten at Apr 17, 2012 at 5:39 pm

    On Tue, Apr 17, 2012 at 10:34 AM, Tim Mooney wrote:

    In regard to: Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types...:


    Todd, welcome and I feel your pain. Trust me, I pushed every way I
    could to use native packages as our module deliver mechanism. However
    we have some odd requirements that make things not work as well with
    RPM (or deb, or gems). Basically we need a mechanism to allow
    multiple versions installed into separate environments (paths on
    disk).
    You make a compelling argument for why this doesn't map well to native
    packaging tools. While it is possible to have multiple copies of an RPM
    installed simultaneously, it would be a kludge in this case.


    Something like pm2rpm and pm2deb is very likely something we'll need
    to make the lives of Puppet Users happy.
    Now that puppet has drug me into the ruby world, I've started down the
    path of RPM packaging of gems. gem2rpm helped me get started. Having
    something that works very similar to that would be a big help to those
    that are experienced with ruby & gems.

    Whatever you choose, though, there needs to be a way for admins to query
    a client and find out

    - what puppet modules are installed
    - where each instance of the module is installed
    - what "version" is present in each instance

    Absolutely. This is the functionality we'll have available in Puppet.

    # puppet module list
    /etc/puppetlabs/puppet/production/modules
    └── nigelkersten-testmac (v0.0.2)
    /opt/puppet/share/puppet/modules
    ├── puppetlabs-pe_accounts (v1.0.2)
    ├── puppetlabs-pe_compliance (v0.0.6)
    ├── puppetlabs-pe_mcollective (v0.0.43)
    └── puppetlabs-stdlib (v2.3.1)

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Walter Heck at Apr 17, 2012 at 6:19 pm

    On Apr 18, 2012 1:39 AM, "Nigel Kersten" wrote:

    Absolutely. This is the functionality we'll have available in Puppet.

    # puppet module list
    /etc/puppetlabs/puppet/production/modules
    └── nigelkersten-testmac (v0.0.2)
    /opt/puppet/share/puppet/modules
    ├── puppetlabs-pe_accounts (v1.0.2)
    ├── puppetlabs-pe_compliance (v0.0.6)
    ├── puppetlabs-pe_mcollective (v0.0.43)
    └── puppetlabs-stdlib (v2.3.1)
    Just checking since that example mentions puppet enterprise modules: this
    will be in the community edition as well, right?

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Kelsey Hightower at Apr 17, 2012 at 6:27 pm
    On Tue, Apr 17, 2012 at 2:19 PM, Walter Heck wrote:
    On Apr 18, 2012 1:39 AM, "Nigel Kersten" wrote:

    Absolutely. This is the functionality we'll have available in Puppet.

    # puppet module list
    /etc/puppetlabs/puppet/production/modules
    └── nigelkersten-testmac (v0.0.2)
    /opt/puppet/share/puppet/modules
    ├── puppetlabs-pe_accounts (v1.0.2)
    ├── puppetlabs-pe_compliance (v0.0.6)
    ├── puppetlabs-pe_mcollective (v0.0.43)
    └── puppetlabs-stdlib (v2.3.1)
    Just checking since that example mentions puppet enterprise modules: this
    will be in the community edition as well, right?
    Yep, the next release of Puppet open source will have it baked in.

    --
    Kelsey Hightower
    Solutions Engineer
    Puppet Labs
    1-678-471-9501

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Walter Heck at Apr 17, 2012 at 6:29 pm
    Yeah, right after that email I saw the 2.7.14rc1 release notes and
    answered my own question, my apologies :)
    On Wed, Apr 18, 2012 at 02:26, Kelsey Hightower wrote:
    On Tue, Apr 17, 2012 at 2:19 PM, Walter Heck wrote:

    On Apr 18, 2012 1:39 AM, "Nigel Kersten" wrote:

    Absolutely. This is the functionality we'll have available in Puppet.

    # puppet module list
    /etc/puppetlabs/puppet/production/modules
    └── nigelkersten-testmac (v0.0.2)
    /opt/puppet/share/puppet/modules
    ├── puppetlabs-pe_accounts (v1.0.2)
    ├── puppetlabs-pe_compliance (v0.0.6)
    ├── puppetlabs-pe_mcollective (v0.0.43)
    └── puppetlabs-stdlib (v2.3.1)
    Just checking since that example mentions puppet enterprise modules: this
    will be in the community edition as well, right?
    Yep, the next release of Puppet open source will have it baked in.

    --
    Kelsey Hightower
    Solutions Engineer
    Puppet Labs
    1-678-471-9501

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.


    --
    Walter Heck

    --
    follow @walterheck on twitter to see what I'm up to!
    --
    Check out my new startup: Server Monitoring as a Service @ http://tribily.com
    Follow @tribily on Twitter and/or 'Like' our Facebook page at
    http://www.facebook.com/tribily

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Kelsey Hightower at Apr 17, 2012 at 6:43 pm

    On Tue, Apr 17, 2012 at 2:28 PM, Walter Heck wrote:

    Yeah, right after that email I saw the 2.7.14rc1 release notes and
    answered my own question, my apologies :)

    No worries, we're here to help.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Stefan Heijmans at Apr 17, 2012 at 7:23 pm
    Hi,
    What will be the option(s) for Puppet users with no internet connection
    (not allowed), if things start to depend more on PMT and Puppet Forge?
    Will we be able to make a local repo and do something like a 'puppet module
    localinstall' ?



    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/mt4aK9XjSnYJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 16, '12 at 9:51p
activeApr 17, '12 at 7:23p
posts9
users6
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase