librarian-puppet vs R10K

[Alex Harvey]

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

[R.I.Pienaar]

The extra features you dont need are optional. But one day when you need them
it might be handy that they exist?

r10k doesnt do dependencies on its own and thats a pain, I prefer it but wish
it did handle dependencies

[Steve Traylen]

On Thu, 2016-01-28 at 06:40 -0800, 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.
>

There's another one to consider
https://github.com/cernops/jens
it recently got an update to accept hook calls from gitlab. We get
our git pushes deployed in 0.4s now. 

[Christopher Wood]

The requirement to "deploy code in complex ways" sounds like an "enterprise" thing. On the one hand, these companies may have few spare cycles for synchronizing configurations across disparate customer-facing products. On the other hand, there can be certain strategically important environments whose change managment is subject to agreements with major customers and operate on a different set of timelines. On the third hand, there can be a myriad of currently-unknown reasons why you would need the flexibility to do something complicated.

Not to say that r10k versus other things (monolithic repositories for one) haven't been a subject of intense debate here too, they have. My current thinking is that we can more maintainably use a subset of r10k functionality than bolt stuff on to a simpler system on an ad-hoc basis.

I think of things like ldap/r10k/radius as items which it really helps to already have when you start getting large and complicated problems.

> --
> 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 [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/639366f5-0fc8-47f8-a1ed-541c79dbc07c%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/639366f5-0fc8-47f8-a1ed-541c79dbc07c%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[Garrett Honeycutt]

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

[Alex Harvey]

On Friday, January 29, 2016 at 6:15:41 AM UTC+11, Garrett Honeycutt wrote:

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.

Thanks.  Your slides are just what I needed to see.  And I didn't know about librarian-puppet-simple and I'm glad I do now.  Yes, dependency resolution is indeed a mixed blessing.  When you say you implement both do you mean you use librarian-puppet-simple on the CI side of the pipeline and R10K on the deployment to Puppet masters side?

 

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.

It may be a documentation problem that I'm struggling with.  You don't happen to know of any code or documentation that shows how to R10K in the build pipeline?  By the way, Librarian-puppet does support caching via $LIBRARAN_PUPPET_TMP, which can point to a long-lived directory on the CI server.  So, actually, Librarian-puppet has never been a bottleneck for me, and unnoticeable relative to the time it takes all the tests to run.

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.

I'd love to know more about this. :) 

[Alex Harvey]

On Friday, January 29, 2016 at 2:31:14 AM UTC+11, Steve Traylen wrote:

There's another one to consider
https://github.com/cernops/jens
it recently got an update to accept hook calls from gitlab. We get
our git pushes deployed in 0.4s now. 

Thanks I'll keep it in mind!