On Wed, Jan 15, 2014 at 5:06 PM, Deepak Giridharagopal <
dee...@puppetlabs.com> wrote:
> On Wed, Jan 15, 2014 at 2:20 PM, Andy Parker <a...@puppetlabs.com> 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 puppet-dev+unsubscr...@googlegroups.com.
> 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
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/CANhgQXsvM%3DZDO2erVgyzi3PTUMKea54uZAKMod-D2k9noy5CWg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
