On Fri, Jan 10, 2014 at 6:37 AM, Erik Dalén <[email protected]>wrote:
> 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. > > The problem comes down to managing the LOAD_PATH while puppet is running and loading code. Moving puppet to use modules, even internally, would bring this problem more to the fore and maybe push us to find a solution. > > 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. > -- 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/CANhgQXswVY6FVOY54ff5rOLdxYDop7BzRdpjv8yyqeeOAGH5cA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
