FAQ
Currently and going forward people will be running multiple versions
of puppet. What are the plans for puppet compatibility with Modules?

Thinking we may want to be able to specify what version of Puppet is
running and ask for the compatible module. (Which may be the same).

Thanks,
Brian

--
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

  • Ryan Coleman at May 17, 2012 at 4:05 pm

    On Thu, May 17, 2012 at 4:43 AM, Brian Gupta wrote:
    Currently and going forward people will be running multiple versions
    of puppet. What are the plans for puppet compatibility with Modules?

    Thinking we may want to be able to specify what version of Puppet is
    running and ask for the compatible module. (Which may be the same).
    Hi Brian,

    Would you like to specify Puppet compatibility in each of your
    modules, perhaps in the Modulefile? Expressing that this module is
    compatibile with versions less than or equal to X, greater than or
    equal to X or exactly equal to X? If so, looks like we've got a ticket
    tracking that feature request.
    http://projects.puppetlabs.com/issues/13598

    --Ryan

    --
    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.
  • Brian Gupta at May 17, 2012 at 4:24 pm

    On Thu, May 17, 2012 at 12:05 PM, Ryan Coleman wrote:
    On Thu, May 17, 2012 at 4:43 AM, Brian Gupta wrote:
    Currently and going forward people will be running multiple versions
    of puppet. What are the plans for puppet compatibility with Modules?

    Thinking we may want to be able to specify what version of Puppet is
    running and ask for the compatible module. (Which may be the same).
    Hi Brian,

    Would you like to specify Puppet compatibility in each of your
    modules, perhaps in the Modulefile? Expressing that this module is
    compatibile with versions less than or equal to X, greater than or
    equal to X or exactly equal to X? If so, looks like we've got a ticket
    tracking that feature request.
    http://projects.puppetlabs.com/issues/13598
    Sounds good, and sounds like it addresses the basic needs. (That
    metadata, I think, will be very important.)

    Will general best practice for forge modules to be developed against
    current latest puppet version, or maintain backward compatibility
    going forward? e.g. - let's say there is a version of a module that
    works with 2.7, when Telly ships will the plan be for the modules to
    be required to support both puppet versions, or just Telly? Or are you
    guys thinking that there will be separate modules for different
    versions of puppet? (Perhaps you guys aren't there yet in your
    planning?)

    Thanks,
    Brian
    --
    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.
  • Ryan Coleman at May 17, 2012 at 4:38 pm

    On Thu, May 17, 2012 at 9:23 AM, Brian Gupta wrote:
    Will general best practice for forge modules to be developed against
    current latest puppet version, or maintain backward compatibility
    going forward? e.g. - let's say there is a version of a module that
    works with 2.7, when Telly ships will the plan be for the modules to
    be required to support both puppet versions, or just Telly? Or are you
    guys thinking that there will be separate modules for different
    versions of puppet? (Perhaps you guys aren't there yet in your
    planning?)
    I'd love to hear what the communities thoughts are here! :-)

    From my perspective, I think it's up to the module author to determine
    what their needs are and author modules accordingly. If they can only
    run 2.6 and want to author modules that aren't compatible with some
    aspect of 2.7, that's perfectly acceptable. They'll just need to
    specify that so those using 2.7 don't install a module that doesn't
    work for them. They'd have to re-evaluate their module when a new
    version (like Telly) ships.

    I added a comment to that ticket suggesting an idea to take the burden
    of specifying compatibility off of module author. Perhaps for modules
    that provide spec tests, we could automatically test that module
    against a matrix of puppet, facter and ruby versions to set and
    maintain what the module is compatible with every time a new version
    of puppet or facter is released. Just a thought.. and certainly that
    could be optional to authors who would rather manually specify
    compatibility.

    --
    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.
  • Brian Gupta at May 17, 2012 at 4:56 pm

    On Thu, May 17, 2012 at 12:38 PM, Ryan Coleman wrote:
    On Thu, May 17, 2012 at 9:23 AM, Brian Gupta wrote:
    Will general best practice for forge modules to be developed against
    current latest puppet version, or maintain backward compatibility
    going forward? e.g. - let's say there is a version of a module that
    works with 2.7, when Telly ships will the plan be for the modules to
    be required to support both puppet versions, or just Telly? Or are you
    guys thinking that there will be separate modules for different
    versions of puppet? (Perhaps you guys aren't there yet in your
    planning?)
    I'd love to hear what the communities thoughts are here! :-)

    From my perspective, I think it's up to the module author to determine
    what their needs are and author modules accordingly. If they can only
    run 2.6 and want to author modules that aren't compatible with some
    aspect of 2.7, that's perfectly acceptable. They'll just need to
    specify that so those using 2.7 don't install a module that doesn't
    work for them. They'd have to re-evaluate their module when a new
    version (like Telly) ships.
    Ah I had envisioned that the long term plan was for there to be core
    modules that were written with best practices and that unless you were
    doing something really funky, they would meet most people's needs.
    (Either through some sort of official process, or crowd-sourced
    voting/rating/self-selection).
    I added a comment to that ticket suggesting an idea to take the burden
    of specifying compatibility off of module author. Perhaps for modules
    that provide spec tests, we could automatically test that module
    against a matrix of puppet, facter and ruby versions to set and
    maintain what the module is compatible with every time a new version
    of puppet or facter is released. Just a thought.. and certainly that
    could be optional to authors who would rather manually specify
    compatibility.
    Hmmm.. a thought (may be to much).. what if you also tracked
    incompatible versions. That way if someone wanted to test it with a
    version of puppet that the author didn't have an opportunity to test,
    someone could submit a testing patch marking it as compatible or
    incompatible with specific version(s)?
    --
    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.
  • Nan Liu at May 17, 2012 at 5:04 pm

    On Thu, May 17, 2012 at 9:55 AM, Brian Gupta wrote:
    On Thu, May 17, 2012 at 12:38 PM, Ryan Coleman wrote:
    On Thu, May 17, 2012 at 9:23 AM, Brian Gupta wrote:
    Will general best practice for forge modules to be developed against
    current latest puppet version, or maintain backward compatibility
    going forward? e.g. - let's say there is a version of a module that
    works with 2.7, when Telly ships will the plan be for the modules to
    be required to support both puppet versions, or just Telly? Or are you
    guys thinking that there will be separate modules for different
    versions of puppet? (Perhaps you guys aren't there yet in your
    planning?)
    I'd love to hear what the communities thoughts are here! :-)

    From my perspective, I think it's up to the module author to determine
    what their needs are and author modules accordingly. If they can only
    run 2.6 and want to author modules that aren't compatible with some
    aspect of 2.7, that's perfectly acceptable. They'll just need to
    specify that so those using 2.7 don't install a module that doesn't
    work for them. They'd have to re-evaluate their module when a new
    version (like Telly) ships.
    Ah I had envisioned that the long term plan was for there to be core
    modules that were written with best practices and that unless you were
    doing something really funky, they would meet most people's needs.
    (Either through some sort of official process, or crowd-sourced
    voting/rating/self-selection).
    I can't speak of the precise plans, but in terms of verifying module
    compatibility with specific puppet version, I've found rspec-puppet to
    be really helpful. Rather than depend on some arbitrary meta-tag, it's
    much more reliable to have automated tests verify the module works
    with specific puppet version.

    In the puppetlabs modules that provide rspec-puppet tests, rake spec
    run will verify the modules not only compiles in your puppet
    environment, but the correct resources and relational dependencies
    meet the author expectation.
    I added a comment to that ticket suggesting an idea to take the burden
    of specifying compatibility off of module author. Perhaps for modules
    that provide spec tests, we could automatically test that module
    against a matrix of puppet, facter and ruby versions to set and
    maintain what the module is compatible with every time a new version
    of puppet or facter is released. Just a thought.. and certainly that
    could be optional to authors who would rather manually specify
    compatibility.
    Hmmm.. a thought (may be to much).. what if you also tracked
    incompatible versions. That way if someone wanted to test it with a
    version of puppet that the author didn't have an opportunity to test,
    someone could submit a testing patch marking it as compatible or
    incompatible with specific version(s)?
    Writing spec tests certainly puts a higher demand on module author,
    but I think it's really worthwhile. I would personally love to see
    puppet-lint, rspec-puppet, and in the long term maybe even acceptance
    test to validate different OS support and post those results in Forge
    rather than depend on a person to constantly keep up with new
    releases.

    Tim Sharpe who wrote rspec-puppet have an example for testing modules
    that's worthwhile as follow up reads:

    http://rspec-puppet.com/
    http://bombasticmonkey.com/2012/03/02/automatically-test-your-puppet-modules-with-travis-ci/

    Thanks,

    Nan

    --
    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.
  • Pieter van de Bruggen at May 17, 2012 at 6:41 pm

    On Thu, May 17, 2012 at 10:03 AM, Nan Liu wrote:
    On Thu, May 17, 2012 at 9:55 AM, Brian Gupta wrote:
    On Thu, May 17, 2012 at 12:38 PM, Ryan Coleman wrote:
    On Thu, May 17, 2012 at 9:23 AM, Brian Gupta wrote:
    Will general best practice for forge modules to be developed against
    current latest puppet version, or maintain backward compatibility
    going forward? e.g. - let's say there is a version of a module that
    works with 2.7, when Telly ships will the plan be for the modules to
    be required to support both puppet versions, or just Telly? Or are you
    guys thinking that there will be separate modules for different
    versions of puppet? (Perhaps you guys aren't there yet in your
    planning?)
    I'd love to hear what the communities thoughts are here! :-)

    From my perspective, I think it's up to the module author to determine
    what their needs are and author modules accordingly. If they can only
    run 2.6 and want to author modules that aren't compatible with some
    aspect of 2.7, that's perfectly acceptable. They'll just need to
    specify that so those using 2.7 don't install a module that doesn't
    work for them. They'd have to re-evaluate their module when a new
    version (like Telly) ships.
    Ah I had envisioned that the long term plan was for there to be core
    modules that were written with best practices and that unless you were
    doing something really funky, they would meet most people's needs.
    (Either through some sort of official process, or crowd-sourced
    voting/rating/self-selection).
    I can't speak of the precise plans, but in terms of verifying module
    compatibility with specific puppet version, I've found rspec-puppet to
    be really helpful. Rather than depend on some arbitrary meta-tag, it's
    much more reliable to have automated tests verify the module works
    with specific puppet version.

    In the puppetlabs modules that provide rspec-puppet tests, rake spec
    run will verify the modules not only compiles in your puppet
    environment, but the correct resources and relational dependencies
    meet the author expectation.
    I added a comment to that ticket suggesting an idea to take the burden
    of specifying compatibility off of module author. Perhaps for modules
    that provide spec tests, we could automatically test that module
    against a matrix of puppet, facter and ruby versions to set and
    maintain what the module is compatible with every time a new version
    of puppet or facter is released. Just a thought.. and certainly that
    could be optional to authors who would rather manually specify
    compatibility.
    Hmmm.. a thought (may be to much).. what if you also tracked
    incompatible versions. That way if someone wanted to test it with a
    version of puppet that the author didn't have an opportunity to test,
    someone could submit a testing patch marking it as compatible or
    incompatible with specific version(s)?
    Writing spec tests certainly puts a higher demand on module author,
    but I think it's really worthwhile. I would personally love to see
    puppet-lint, rspec-puppet, and in the long term maybe even acceptance
    test to validate different OS support and post those results in Forge
    rather than depend on a person to constantly keep up with new
    releases.

    Tim Sharpe who wrote rspec-puppet have an example for testing modules
    that's worthwhile as follow up reads:

    http://rspec-puppet.com/

    http://bombasticmonkey.com/2012/03/02/automatically-test-your-puppet-modules-with-travis-ci/

    Thanks,

    Nan

    --
    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.
    To this end, we have actually been talking about plans to re-evaluate the
    kinds of data that goes into the metadata file, and better support for
    particular Puppet versions is one such improvement. In addition, we are
    also planning to improve the presentation of modules on the Puppet Forge,
    exposing more information like supported Puppet versions (and possibly even
    more interesting things, like the results of running the tests under
    various Puppet versions and operating systems).

    I'd love to hear more about what would make a difference to your workflow
    and how we might be able to better accomodate it.

    --
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 17, '12 at 11:44a
activeMay 17, '12 at 6:41p
posts7
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase