W dniu wtorek, 21 stycznia 2014 19:43:00 UTC+1 użytkownik Andy Parker napisał: > > On Wed, Jan 15, 2014 at 5:06 PM, Deepak Giridharagopal < > [email protected] <javascript:>> wrote: > >> On Wed, Jan 15, 2014 at 2:20 PM, Andy Parker >> <[email protected]<javascript:> >> > 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 >
I think, a quite harder may be to identify specs that are related to these types/providers. -- 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/024026cd-c784-46c8-ba43-2ab18957cd64%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
