librarian-puppet vs git superproject?

[Ryan Bowlby]

Can anyone comment on their experiences with librarian-puppet or using git superproject with per puppet module repositories? We are in the midst of determining which route is optimal for our environment. It seems like using git superprojects would mean one less new tool for everyone to learn. What then would be the advantages of librarian-puppet?

Thanks,

Ryan Bowlby

[Dan Bode]

On Mon, Jul 23, 2012 at 3:43 PM, Ryan Bowlby <rbow...@gmail.com> wrote:

Can anyone comment on their experiences with librarian-puppet or using git superproject with per puppet module repositories?

I tried using git submodules for a long time. I found that I just could not keep up with updating changed modules in two places (the module repo and the superproject repo). I wound up with projects that were never quite in sync.

My other problem is that the puppet ecosystem (the forge, etc) does not really have a concept of a super project. All that it has is modules.

I wound up switching to yaml files that specify dependencies with a rake task. This way, I can have superprojects that are themselves puppet modules. It also allows me to only check in the fact that master of all modules should work with master of its dependencies (which is almost always the state that I want checked-in)

For an example, have a look at the rake tasks for the puppetlabs-openstack modules:

https://github.com/puppetlabs/puppetlabs-openstack/blob/master/Rakefile

I would love to see something like this eventually expanded into the Modulefile.

I havent really looked at librarian yet, but I am interested.

 

We are in the midst of determining which route is optimal for our environment. It seems like using git superprojects would mean one less new tool for everyone to learn. What then would be the advantages of librarian-puppet?

Thanks,

Ryan Bowlby

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4Kf47PY2sIwJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[David Schmitt]

I've played around with repo (android's git forest manager) but it's
just too much complexity for non-developers. I've now switched to
everything in one .git and it's just so much easier to manage. Putting
external modules in a separate branch and then subtree merge is a
viable, albeit still too complex, way for tracking externals.


Best Regards, David

[Ohad Levy]

I myself still use  submodules, as most of my modules are not in the forge, maybe that would change once pulp will offer an alternative.

Ohad

Best Regards, David

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.

[Ryan Bowlby]

Thanks all, we've decided to stick with git super project and per module repositories. Some of the modules will be a clone from github, but most are internal. It seems to suit our needs and we don't see a reason to implement librarian-puppet.

Ohad, I setup pulp at work and it's pretty good (tasks get stuck occasionally). We don't use consumer though, we manage packages via puppet. I'm actually thinking of creating a pulp defines for some of the pulp-server tasks "pulp-admin repo create". I guess I should publish our existing pulp module.

I take it you're talking about a future release where pulp has a plugin model and is more of a generalized "manage all the things" tool? Is there going to be a plugin for the forge or something?

-Ryan

[Erik Dalén]

I've been using git subtree merge for this. I think it is better than
git submodules as it limits the complexity to only the people merging
and updating external modules (and it's really not that complex). But
people can continue to commit fixes without much hassle or updating
multiple repositories.

Some wrapper scripts against git subtree are here:
https://github.com/apenwarr/git-subtree/
Or in contrib in git 1.7.11+

One advantage of librarian-puppet though is that you can effectively
create topic branches where only one module is denomalized but the
rest are following the latest version you have. That sort of workflow
is clunky at best with submodules/subtrees.

--
Erik Dalén

[Dan Bode]

On Mon, Jul 23, 2012 at 8:43 PM, Dan Bode <d...@puppetlabs.com> wrote:

On Mon, Jul 23, 2012 at 3:43 PM, Ryan Bowlby <rbow...@gmail.com> wrote:

Can anyone comment on their experiences with librarian-puppet or using git superproject with per puppet module repositories?

I tried using git submodules for a long time. I found that I just could not keep up with updating changed modules in two places (the module repo and the superproject repo). I wound up with projects that were never quite in sync.

My other problem is that the puppet ecosystem (the forge, etc) does not really have a concept of a super project. All that it has is modules.

I wound up switching to yaml files that specify dependencies with a rake task. This way, I can have superprojects that are themselves puppet modules. It also allows me to only check in the fact that master of all modules should work with master of its dependencies (which is almost always the state that I want checked-in)

For an example, have a look at the rake tasks for the puppetlabs-openstack modules:

https://github.com/puppetlabs/puppetlabs-openstack/blob/master/Rakefile

I would love to see something like this eventually expanded into the Modulefile.

I havent really looked at librarian yet, but I am interested.

I probably should have looked into puppet librarian before sending this email. Its very similar to the custom yaml files with rake tasks that I had mentioned before. I should actually be able to remove my custom yaml files and drop in puppet-librarian.