W dniu czwartek, 16 stycznia 2014 01:01:38 UTC+1 użytkownik James Turnbull napisał: > > Andy Parker wrote: > > On Wed, Jan 15, 2014 at 1:21 PM, Dustin J. Mitchell > > <[email protected]<javascript:> > > <mailto:[email protected] <javascript:>>> wrote: > > > > On Wed, Jan 15, 2014 at 4:20 PM, Andy Parker > > <[email protected]<javascript:> > > <mailto:[email protected] <javascript:>>> wrote: > > > * Tier2 code ideally won't live inside the puppet repo at all > > .. > > > 1. create a "modules" directory that is a peer of "lib" in the > > puppet repo > > > > These seem contradictory.. > > > > > > They are. I'm thinking that the modules directory would live only as > > long as it takes to extract them out in a way that produces reasonable > > modules for publishing on the forge. The reason for the modules step is > > so that we can keep shipping a working system as the work is going on > > without having to keep the changes on a long lived branch. > > > > The contradiction is resolved after we complete the final step "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." > > > > I think this is a broadly good idea but I've got one concern about the > on ramp to using Puppet. Whatever is done, pull out some/pull out all, > the user experience of getting started with Puppet should remain > seamless or at least as good as it is now. For example, if there's > suddenly another step to get started with Puppet, i.e.: > > 1. Install Puppet. > 2. Add resources. > 3. See Puppet in action. > > Then I think the getting started user experience suffers. Especially > with so many tutorials out there that just assume various resources will > be available. If the user gets some esoteric error (Dog forbid Puppet > having an esoteric error :)) when they try to run a local .pp file or do > a puppet resource then that's a big turn-off. >
I believe separation may be done without rising the learning curve. Once the puppet is split into (a little) core and a gazylion of modules, a (sub)set of modules may be identified to be packaged and distributed as deb, rpm, and so on. Let say there could be a `puppet-modules` or `puppet-standard-modules` package and `puppet` could just depend on it (or at leas recommend it - some packaging systems such as Debian's apt have such a functionality and it sometimes installs recommended packages automatically). So, basically you install puppet as always and you get the puppet and all of it's "standard" types/providers as it is currently. > > Puppet's learning curve can be steep for many users. Let's not make it > any harder. > > Cheers > > James > > -- > * The Docker Book (http://dockerbook.com) > * The LogStash Book (http://logstashbook.com) > * Pro Puppet (http://tinyurl.com/ppuppet2 ) > * Pro Linux System Administration (http://tinyurl.com/linuxadmin) > * Pro Nagios 2.0 (http://tinyurl.com/pronagios) > * Hardening Linux (http://tinyurl.com/hardeninglinux) > > -- Pawel Tomulik -- 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/42da2474-26ec-4ec3-87a0-6091bb072aff%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
