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 > > <dus...@v.igoro.us<javascript:> > > <mailto:dus...@v.igoro.us <javascript:>>> wrote: > > > > On Wed, Jan 15, 2014 at 4:20 PM, Andy Parker > > <an...@puppetlabs.com<javascript:> > > <mailto:an...@puppetlabs.com <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 puppet-dev+unsubscr...@googlegroups.com. 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.
