I've found that when putting stuff in modules that use some shared code like puppetdbquery, you either have to do a pluginsync on the master first, or do some hacks with the ruby load path to load the code directly out of the modulepath. That could be a bit annoying for stuff like naginator or this BSD stuff.
I think there is some bug report for it but can't find it now. On 9 January 2014 20:30, Andy Parker <[email protected]> wrote: > On Wed, Jan 8, 2014 at 3:20 PM, Daniel Pittman <[email protected]>wrote: > >> On Wed, Jan 8, 2014 at 1:09 PM, Andy Parker <[email protected]> wrote: >> > During today's PR triage we spent a long time going over PRs 2227, 2226, >> > 2225, 2034, and 2130. These are all related together and are the >> combination >> > of two different issues. One is that the package provider needs some >> way of >> > passing through arbitrary, unmodelled parameters to the provider (so >> that >> > you can have modifications specific to a provider that don't have any >> > meaning for other providers). The other part was to update the freebsd >> > package provider support for a new packaging system that apparently >> came out >> > in FreeBSD 10. The first change we want to get into the core. The second >> > change pushes to the forefront a problem that has been plaguing us for a >> > long time: there are a lot of systems that puppet can run on, has >> providers >> > for, but we can't maintain inside the core very well (we don't have the >> > expertise, time, or, sometimes, desire), and there are other things >> that we >> > care about quite a lot and can try to take an active role in >> maintaining. >> > >> > So here is the proposal: let's split things into 2 tiers: >> > >> > * Tier 1: these are things that the core team will work to make sure >> are >> > working well, maintain compatibility between puppet releases, and >> give a >> > critical eye to changes >> > * Tier 2: things that are shipped as part of the standard puppet >> system, >> > but are more of a "contrib" status. Those won't be required to >> abide by the >> > same versioning semantics, there is a defined maintainer (or clearly >> > unmaintained) by someone. The exact details of how contrib is >> structured and >> > shipped needs to be worked out, however. >> > >> > So why have a Tier 2 and not just shove everything into modules? One >> reason >> > would be to have things that are "core", but not maintained by the core >> > developers still be visible and close at hand. I would give us a little >> more >> > visibility into what is happening without being a bottleneck. Another >> would >> > be if the maintainer doesn't want to deal with releasing the changes, >> > thinking about version numbers, etc. They would all just be rolled into >> the >> > next puppet release and go along for the ride. >> > >> > So the next questions to answer on this are: >> > >> > * What would be tier 1 and tier 2? >> >> I think the best thing would be that tier 1 types and providers are >> part of the Puppet core, and tier two are modules that are bundled >> into the core and shipped with it. >> >> > I agree that more of what is in core needs to be moved out into modules. I > think having a tier 2 inside the main repo would provide the path to do > that. We can first move some parts into the tier 2 area and then over time > it might just move entirely to a separate module. > > But the question here was actually more of "What actual parts of the > system should be classified as tier 1 and what parts are tier 2?" > > >> > * How should the separation be made evident? >> >> By putting tier 2 code into modules -- and, optimally, making it >> sensible to upgrade them separately -- the division is very clear. >> Core code is core, and non-core code is in modules. >> >> Users who want it to "just work" get a set of modules vetted, tested, >> and shipped that work out of the box. Transparently, no less, because >> we do support types and providers in modules fairly well. >> >> > "vetted" and "tested" are the key things here. These parts of the system > aren't really vetted, nor are they tested. We don't check that the FreeBSD > package providers work, for instance. > > >> It makes it clear looking at the code, too: core things are in core, >> and non-core things get pulled in from a different source when the >> product ships. >> >> > * How should contrib be structured? >> > * Process for gaining or losing a maintainer? >> >> Like any module: put it on the forge, have someone own it. Those >> people could very well be... >> >> > * Who should be the initial maintainers? I think we already have some >> > people who might want to step up for some things (ptomulik for FreeBSD >> > perhaps?) >> >> ...the Puppet Labs paid staff, who work on "Puppet", and now also work >> on things that Puppet ships. If you take the approach of ensuring >> that your team can ship new versions of those modules, you resolve the >> problem of control. >> >> It also means that, eg, ptomulik can ship improvements for the FreeBSD >> tooling ahead of Puppet, and the newer versions will get rolled back >> into core when they are tested, vetted, and ready to be used without >> effort by folks who don't want the complexity of learning our module >> ecosystem -- they just want to get things done. >> >> > I know that this has been talked about for a long time and that we >> already >> > have a lot of projects in flight (and have dropped the ball on so >> many), but >> > if we get some consensus on this, I think we can make some good progress >> > toward getting this all in place. >> >> I suspect your first reaction to this will be "no", or perhaps even >> "hell, no!"; overall, I think that shipping modules with the core is >> actually a good step forward. Many languages -- Ruby, Perl, Python, >> Java, Clojure -- have found this an effective way to manage their core >> and library separation. >> >> > I think that aiming for it is a noble goal, but not where we are right > now. There was one experiment with pulling some things into a module > (nagios, I believe) but that backfired. Wouldn't first putting into place a > clear delineation inside the existing codebase be a good first step in that > direction? > > >> I think there is substantial evidence that this is a good, supportable >> and effective approach to solving exactly this problem, as well as to >> reducing the coupling between "core" and "non-core" modules, and their >> release. >> >> -- >> Daniel Pittman >> ⎋ Puppet Labs Developer – http://puppetlabs.com >> ♲ Made with 100 percent post-consumer electrons >> >> -- >> 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/CAFAW1H%3DHyzVnUaLeBu8ZHbMEKtRq2bW3b_avZzGGT0BLoSOd6Q%40mail.gmail.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/CANhgQXtu_WemuzVgL6Cz%3D8JArdn6XF7NuEOB9AkYz2bTejFZpA%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- Erik Dalén -- 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/CAAAzDLekAwO-Xh55CSD4H1AGFC5Zwe3dWAvCWwxd_H%3DN2_%3DQSQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
