On Wed, Jan 15, 2014 at 5:06 PM, Deepak Giridharagopal < [email protected]> wrote:
> On Wed, Jan 15, 2014 at 2:20 PM, Andy Parker <[email protected]> wrote: > >> 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. >> > > > This is a great thread. So as I've been reading through this and talking > with people on #puppet-dev, I've come around to thinking about it this way: > > * there's code for which Puppet Labs is the maintainer along with the > community > * there's code for which there are only community maintainers > * there's code that's effectively unmaintained > * there's code that's currently in core, but probably shouldn't be (like > the nagios stuff) > > For things where it was a mistake to really be in core in the first place, > I think we should just move that stuff out. I'm really just thinking about > the nagios types here, but maybe there are others. > I mostly agree with that. We move it out (nagios is the most obvious example, I think), but what do we do with it? Just dump it on the forge and leave it? > > For things that are effectively unmaintained, like platforms that nobody > is willing to step up and own...I think we should put those on a path to be > moved out. We're not doing anyone any favors by having that stuff in core > and bit-rotting. > > The other two buckets are the most important ones in my mind. This isn't > really about tiers, but instead about maintained/unmaintained code. As long > as code is maintained, it should be a first-class citizen regardless of > whether or not it's maintained by the community or by puppet labs. The > community is not second-class, which is what I think the word "tier" > implies. > > Unmaintained code, though, is definitely second-class. :) > > So really what I'm talking about is actively seeking out community > maintainers for certain platforms, and giving them commit access. They > handle pull requests for that part of the tree, and generally act as good > stewards (tests pass, obey semver, packaging works, etc). > > So this would be to keep the code in the puppet repo, which is definitely much less work up front. Although I think we should still try to split out the code into modules that live inside the main repo. If nothing else this helps to make the boundaries clearer. > I think in order to get there, we need to do a few things: > > 1. Inventory what we've got in terms of platforms/types/providers > Types/Providers: augeas +- augeas component no providers computer +- computer cron +- crontab exec +- posix +- shell +- windows file +- posix +- windows file +- posix +- windows filebucket no providers group +- aix +- directoryservice +- groupadd +- ldap +- pw +- windows_adsi host +- parsed interface +- cisco k5login no providers macauthorization +- macauthorization mailalias +- aliases maillist +- mailman mcx +- mcxcontent mount +- parsed nagios_command no providers nagios_contact no providers nagios_contactgroup no providers nagios_host no providers nagios_hostdependency no providers nagios_hostescalation no providers nagios_hostextinfo no providers nagios_hostgroup no providers nagios_service no providers nagios_servicedependency no providers nagios_serviceescalation no providers nagios_serviceextinfo no providers nagios_servicegroup no providers nagios_timeperiod no providers notify no providers package +- aix +- appdmg +- apple +- apt +- aptitude +- aptrpm +- blastwave +- dpkg +- fink +- freebsd +- gem +- hpux +- macports +- msi +- nim +- openbsd +- opkg +- pacman +- pip +- pkg +- pkgdmg +- pkgin +- pkgutil +- portage +- ports +- portupgrade +- rpm +- rug +- sun +- sunfreeware +- up2date +- urpmi +- windows +- windows +- yum +- yumhelper.py +- zypper port +- parsed resources no providers router no providers schedule no providers scheduled_task +- win32_taskscheduler selboolean +- getsetsebool selmodule +- semodule service +- base +- bsd +- daemontools +- debian +- freebsd +- gentoo +- init +- launchd +- openbsd +- openrc +- openwrt +- redhat +- runit +- service +- smf +- src +- systemd +- upstart +- windows ssh_authorized_key +- parsed sshkey +- parsed stage no providers tidy no providers user +- aix +- directoryservice +- hpux +- ldap +- pw +- user_role_add +- useradd +- windows_adsi vlan +- cisco whit no providers yumrepo no providers zfs +- zfs zone +- solaris zpool +- zpool This list was created by: for t in `ls lib/puppet/type`; do base=`basename $t ".rb"`; echo $base; if [ -d "lib/puppet/provider/$base" ]; then for p in `ls lib/puppet/provider/$base`; do echo " +- $(basename $p .rb)"; done; else echo " no providers"; fi done > 2. Figure out what subset of those are things Puppet Labs helps maintain > (see Kylo's link) > 3. Figure out what subset of those are like the nagios types in that they > really make sense as external modules > 4. For the rest, begin looking for community maintainers. We can look at > people who have made commits, we can ask on this list, IRC, etc. > > I think once we do that exercise, we can start thinking about the > mechanics of reorganizing the source tree accordingly. I'd suggest that we > reorganize things so that maintainers manage a subtree. > Exactly > > -- > Deepak Giridharagopal / Puppet Labs > > -- > 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/CAOjOXY0D5ZsAeBE87r3kWFvW5YytRBUqc-VtirzC7w-WN1WR5g%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/CANhgQXsvM%3DZDO2erVgyzi3PTUMKea54uZAKMod-D2k9noy5CWg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
