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 <a...@puppetlabs.com> wrote: > On Wed, Jan 8, 2014 at 3:20 PM, Daniel Pittman <dan...@puppetlabs.com>wrote: > >> On Wed, Jan 8, 2014 at 1:09 PM, Andy Parker <a...@puppetlabs.com> 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 puppet-dev+unsubscr...@googlegroups.com. >> 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 > a...@puppetlabs.com > 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 puppet-dev+unsubscr...@googlegroups.com. > 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 puppet-dev+unsubscr...@googlegroups.com. 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.
