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 -- 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Jul 23, 2012 at 3:43 PM, Ryan Bowlby <rbowlby83@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-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
David Schmitt
2012-Jul-24 06:49 UTC
Re: [Puppet Users] librarian-puppet vs git superproject?
On 24.07.2012 00:43, Ryan Bowlby wrote:> 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?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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Jul 24, 2012 at 9:49 AM, David Schmitt <david@dasz.at> wrote:> On 24.07.2012 00:43, Ryan Bowlby wrote: > >> 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? >> > > 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. > >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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@** > googlegroups.com <puppet-users%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en> > . > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Ryan Bowlby
2012-Jul-24 23:39 UTC
Re: [Puppet Users] librarian-puppet vs git superproject?
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 On Tuesday, July 24, 2012 1:00:00 AM UTC-7, ohad wrote:> > > > On Tue, Jul 24, 2012 at 9:49 AM, David Schmitt <david@dasz.at> wrote: > >> On 24.07.2012 00:43, Ryan Bowlby wrote: >> >>> 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? >>> >> >> 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. >> >> > 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-users@googlegroups.com. >> To unsubscribe from this group, send email to puppet-users+unsubscribe@** >> googlegroups.com <puppet-users%2Bunsubscribe@googlegroups.com>. >> For more options, visit this group at http://groups.google.com/** >> group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en> >> . >> >> >-- 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/-/L6w5ahoRnKsJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 24 July 2012 00:43, Ryan Bowlby <rbowlby83@gmail.com> wrote:> 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? >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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Jul 23, 2012 at 8:43 PM, Dan Bode <dan@puppetlabs.com> wrote:> > > On Mon, Jul 23, 2012 at 3:43 PM, Ryan Bowlby <rbowlby83@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.> > >> 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-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.