Ok, let me try to summarize the discussion so far: * Tier1/Tier2 as a basic premise seems to be accepted as a good idea. * Tier2 code ideally won't live inside the puppet repo at all * Tier2 code should be packaged up as modules * Make the separation based on what we (PL) actually test * OR make *everything* Tier2 (no such thing as core providers) * the puppet packages should pull in a select set of modules (and specific versions) and ship those in a vendor modulepath
I think I can be on board with this as an end goal. And I lean toward making everything Tier2. My only concern is the overhead of managing all of those dependencies, it seems like it could quickly lead to a place where we are spending a huge amount of our time just dealing with version numbers. Now for a proposal on how to get there (order might be a little wrong): 1. create a "modules" directory that is a peer of "lib" in the puppet repo 2. select a section of functionality to pull out (nagios might be the first good candidate since we've already tried it once) 3. create a puppet module in the modules directory and move the code and tests to the module 4. Update the rake tasks to run all of the spec tests as well as the spec tests of each module 5. Plumb in a "build" rake task (right now we don't have one). This will be a step that merges the module back into the lib code as part of packaging. 6. Extend puppet's support for modulepath to include a static vendored modules section 7. Change the build/packaging/install scripts to move the modules into the vendored directory instead of merging it into the puppet code 8. Repeat steps 2 and 3 until happy After that is all in place (or just after the first one plumbs in all of the functionality) I think we can then start moving things off to the forge and pulling them in a different way. On Tue, Jan 14, 2014 at 10:52 AM, John Bollinger <[email protected]>wrote: > > > On Monday, January 13, 2014 7:13:20 PM UTC-6, Dustin J. Mitchell wrote: >> >> How about something as simple as a top-level "modules" directory in >> the puppet source, which is installed separately and dynamically >> appended to the modulepath at runtime? That avoids any problems for >> users who set modulepath, allows modules in users' modulepaths to >> override the built-in modules, and doesn't use the inaccurate name >> "contrib". It also makes it easy to move modules in and out of core. >> >> > > I like the idea of a system modulepath wherein reside modules that are > accounted in some way part of Puppet itself, with that being appended > automatically to the user modulepath. I think that will make the change > fairly transparent to users, even if it occurs over several releases. That > would also make it convenient to package the tier-2 stuff separately from > the Puppet core, if so desired, and I think it would be easy to maintain > (as much so as any alternative I can think of, anyway). > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/e6e6170a-3bdd-4b54-88ef-aa2d76b2c88b%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXtmBhipco5pJi0%2BXiwa_Ubir9nWAW5%3DhWYrt-x8-Wi2_g%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
