Hi All, I''m building out my first puppet install and obviously want to leverage modules from the forge. Since I''m using git as the VCS for my puppet configs and most community modules are hosted on github it seems the obvious thing to do is to use either git submodules or subtree merging, but I haven''t used those features in the past so it''s not clear to me the added features are worth the complexity over pulling a tarball of the module into my local git. It does seem contributing back would be easier with one of the git options .... anyway, what methods are you using and how do you like them? Thanks, -Jon -- 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.
I''m a big fan of using read-only submodules, usually to the upstream
project but sometimes to my own fork. The use of submodules makes
getting changes in from upstream trivial. The commands you need to
know are:
git submodule add
git submodule sync
git submodule update --init --recursive
The first command adds a submodule to a working repository, the latter
ensure that all modules are initialized and updated. They are
especially necessary for fresh repo clones.
The area where git''s submodule concept really falls down is
git-archive''s lack of support for recursive descent into modules. Save
yourself a ton of frustration and archive with rsync. Something like:
git checkout FOOCOMMIT
git submodule sync && git submodule update --init --recursive
rsync -vzrP --delete --exclude=''.git'' /path/to/repo/
/path/to/archive/
The Forge seems to encourage the tarball style but, no offense to the
Puppet team, GitHub''s where all the action''s at, in my very
humble
opinion.
On Sun, Feb 26, 2012 at 1:17 PM, Jonathan Proulx <jon@jonproulx.com>
wrote:> Hi All,
>
> I''m building out my first puppet install and obviously want to
> leverage modules from the forge. Since I''m using git as the VCS
for
> my puppet configs and most community modules are hosted on github it
> seems the obvious thing to do is to use either git submodules or
> subtree merging, but I haven''t used those features in the past so
it''s
> not clear to me the added features are worth the complexity over
> pulling a tarball of the module into my local git. It does seem
> contributing back would be easier with one of the git options ....
>
> anyway, what methods are you using and how do you like them?
>
> Thanks,
> -Jon
>
> --
> 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.
>
--
Brian L. Troutwine
--
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 Sun, Feb 26, 2012 at 1:54 PM, Brian Troutwine <brian@troutwine.us> wrote:> I''m a big fan of using read-only submodules, usually to the upstream > project but sometimes to my own fork. The use of submodules makes > getting changes in from upstream trivialI agree that github is where it''s at. On of the things I liked looking at chef (if I can mention competing systems :) was their integrated module system does a little git dance to (allegedly) make this all happen, I should probably look and see what they are actually doing in there. One of my concerns with submodule is the need to treat them differently from other subtrees. Having a small team working on the configuration system would everyone need to remember (or remember to check) which modules were local and which were from the forge? -- 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 Sun, Feb 26, 2012 at 2:18 PM, Jonathan Proulx <jon@jonproulx.com> wrote:> On Sun, Feb 26, 2012 at 1:54 PM, Brian Troutwine <brian@troutwine.us> wrote: >> I''m a big fan of using read-only submodules, usually to the upstream >> project but sometimes to my own fork. The use of submodules makes >> getting changes in from upstream trivial > > I agree that github is where it''s at. On of the things I liked > looking at chef (if I can mention competing systems :) was their > integrated module system does a little git dance to (allegedly) make > this all happen, I should probably look and see what they are > actually doing in there.It''s slick, certainly. There''s a tooling deficit _around_ Puppet, in some part because there''s a focus on general applicability. Much of Chef''s tooling breaks--or, at least, did--in the absence of git. I wouldn''t mind seeing a Golden Path of convention over configuration come out of PuppetLabs, along with the related tooling. A heavy revamp of the Forge to work not unlike rubygems for module producers and like ruby-toolbox.com for consumers. I seem to recall changes to the Forge being mentioned on this list, but I don''t recall the details provided, if any were given. As it is, speaking an exclusive git/Puppet user, the Forge acts as an okay-ish module search engine but doesn''t add much value otherwise. Having to upload release tarballs feels anachronistic and, frankly, I''ve not bothered.> One of my concerns with submodule is the need to treat them > differently from other subtrees. Having a small team working on the > configuration system would everyone need to remember (or remember to > check) which modules were local and which were from the forge?Yes, unfortunately. The git porcelain here isn''t all that helpful. I''ve seen a few projects discussed in #git that abstracts over the two approaches, but I''ve not used them and the most popular--as I understand it--hasn''t seen an update in a year: https://github.com/apenwarr/git-subtree I''d imagine the cognitive load on folks will be less if you stick with one approach or the other. I tend to get confused in projects that are mixed, but that could be me projecting a personal deficiency as normal and justifiable. :) Certainly soliciting opinions in a git-specific mailing-list would not hurt.> -- > 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. >-- Brian L. Troutwine -- 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.
William Van Hevelingen
2012-Feb-26 20:25 UTC
Re: [Puppet Users] Managing community modules.
Hi Jon, On 02/26/2012 10:17 AM, Jonathan Proulx wrote:> Hi All, > > I''m building out my first puppet install and obviously want to > leverage modules from the forge. Since I''m using git as the VCS for > my puppet configs and most community modules are hosted on github it > seems the obvious thing to do is to use either git submodules or > subtree merging, but I haven''t used those features in the past so it''s > not clear to me the added features are worth the complexity over > pulling a tarball of the module into my local git. It does seem > contributing back would be easier with one of the git options .... > > anyway, what methods are you using and how do you like them? > > Thanks, > -Jon >We use git submodules for both internal and public modules since the github repositories are often ahead of the tarballs on the forge. Make sure to have an internal mirror of any submodules you clone from github in case github is down or the owner deletes the repository. We try to use modules forked or created by puppetlabs and contribute back any features we need. Otherwise we fork a module on github configure it for our environment or improve it and push it back to github. Using git submodules allows us to share non-secret puppet code internally to devs and junior sysadmins who can then push back test branches that the Senior Sysadmins can review and merge in. Also using git/puppet environments you can branch in a submodule and test your changes quite easily and then push them to github and click the pull request button in github. :) -- William Van Hevelingen <https://github.com/blkperl>https://github.com/pdxcat -- 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.