On 1/28/16 9:40 AM, Alex Harvey wrote: > Hi all, > > I am interested in the future of the Librarian-puppet project - to find > out how many people are still using it, and if there are people out > there who actually prefer it over R10K. > > I recently looked into R10K for a few projects I was working on, and I > found it to be surprisingly complicated. It had many features I didn't > seem to need, features that overlap with features provided by > Jenkins/Bamboo, and appeared designed with a view to helping people > deploy code in complex ways, help them to test short lived branches on > Puppet masters, etc. This might have made sense once, but if you're > doing all your development in a test-driven fashion in > Vagrant/Rspec-puppet/Beaker, I can't see a need for R10K's features, and > concluded it was mainly just a lot harder to understand than > Librarian-puppet. I do see that it performs better, but again, > Librarian-puppet has never been a bottleneck. > > Other views most appreciated. > > With best regards, > Alex
Hi Alex, I generally implement both for customers. Though I use Dan Bode's librarian-puppet-simple which purposely does not handle dependencies. I spoke at a couple Puppet Camp's regarding dealing with modules and here are slides[1] explaining the pro's and con's of the different approaches. R10k is great, even with a build pipeline, because the caching feature really speeds up the build jobs over librarian-puppet, which will need to download the git repo's each time. I maintain a bunch of modules that you might consider as common or base to an OS such as SSH, NTP, PAM, hosts, timezone, NFS, etc as well as code for modeling PuppetDB, Puppet agents and masters that are tracked in a Puppetfile[2]. Since that has its own life cycle outside of the clients' and does not need git branch to environment mapping it is maintained with librarian-puppet-simple. I've also used r10k to build Puppet platform as a service for large enterprises that have many products and teams with their own distinct environments. This allows many teams to leverage each others work while giving them their own autonomy with regards to number of environments, testing abilities, module versions and release schedules. [1] - http://www.slideshare.net/gh/20141111-multiple-approaches-to-managing-puppet-modules-puppet-camp-seattle [2] - https://github.com/ghoneycutt/puppet-modules Best regards, -g -- Garrett Honeycutt @learnpuppet Puppet Training with LearnPuppet.com Mobile: +1.206.414.8658 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/56AA68D0.4070304%40garretthoneycutt.com. For more options, visit https://groups.google.com/d/optout.
