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.
