Hi there, Like most of us, I put my Puppet module code to git repos. I''d like to know, how to deal with third-party module w/ git? For instance, to use Puppet Labs Standard Libary, I put "stdlib" along with my own modules. Every time I want to update "stdlib", I have to remove stdlib directory, then get the latest version, move it to my modules directory. This is very inconvenient, obviously. So how do you guys manage third-party modules, except using git submodule? Thanks. -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
On Aug 6, 2013, at 5:27 AM, Feifei Jia <feifei.j@gmail.com> wrote:> This is very inconvenient, obviously. So how do you guys manage third-party modules, except using git submodule? Thanks.I use librarian-puppet https://github.com/rodjek/librarian-puppet for one of my projects. It''s basically a dependency management system for Puppet modules, a la Maven, Ruby gems, etc. The problem is that I find its resolution of versions quite unreliable, for example grabbing apache 0.8.1 when 0.6.x is specified. The author is working on a replacement called Henson https://github.com/wfarr/henson. Librarian-puppet has some (undocumented) functionality that looks like it''ll allow you to cache your dependencies and work from those, so I''m considering looking into that and committing the cardinal version control sin of checking in 3rd-party dependencies. For right now, tho, despite my concerns with it, I find it a huge improvement over submodules or managing others modules in my source. An alternative may be to separate out your own modules from 3rd-party modules. As it is, I put librarian-puppet-managed modules into a "library_modules" folder and ones developed just for a given project into "modules". That will give you some separation of code and at least make it easier to manage updates. -- Brian Lalor blalor@bravo5.org http://github.com/blalor -- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Thanks for the reply, Brian.
I have looked into librarian-puppet, a good tool, just like ruby bundler.
Will give it a try.
And I''m also interested in your alternative way to organise your
module.
Could you explain more on that? What the modules directory structure look
like? Just like the following?
/etc/puppet/modules/{library_modules, your_module_a, your_module_z}
On Tuesday, August 6, 2013 5:52:12 PM UTC+8, blalor
wrote:>
> On Aug 6, 2013, at 5:27 AM, Feifei Jia <feif...@gmail.com
<javascript:>>
> wrote:
>
> This is very inconvenient, obviously. So how do you guys manage
> third-party modules, except using git submodule? Thanks.
>
>
> I use librarian-puppet https://github.com/rodjek/librarian-puppet for one
> of my projects. It''s basically a dependency management system for
Puppet
> modules, a la Maven, Ruby gems, etc. The problem is that I find its
> resolution of versions quite unreliable, for example grabbing apache 0.8.1
> when 0.6.x is specified. The author is working on a replacement called
> Henson https://github.com/wfarr/henson.
>
> Librarian-puppet has some (undocumented) functionality that looks like
> it''ll allow you to cache your dependencies and work from those, so
I''m
> considering looking into that and committing the cardinal version control
> sin of checking in 3rd-party dependencies. For right now, tho, despite my
> concerns with it, I find it a huge improvement over submodules or managing
> others modules in my source.
>
> An alternative may be to separate out your own modules from 3rd-party
> modules. As it is, I put librarian-puppet-managed modules into a
> "library_modules" folder and ones developed just for a given
project into
> "modules". That will give you some separation of code and at
least make it
> easier to manage updates.
>
> --
> Brian Lalor
> bla...@bravo5.org <javascript:>
> http://github.com/blalor
>
>
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Hi Faifel, this is the way I like to organize my modues: modules/$environment/$type where $environment usually is one of dev qa stg and prd and type is one of base common and roles. So in a typical configuration it would be something like: modules/dev/common modules/dev/base modules/dev/roles modules/qa/common modules/qa/base modules/qa/roles modules/stg/common modules/stg/base modules/stg/roles Now base contain base modules that configure your OS. ie: companyname_ldap companyname_ntp companyname_network companyname_mail and usually you have something like: companyname_base that will include all the rest of the modules. Common will contain all the external modules apache postfix ldap Roles will contain application modules companyname_role_frontend companyname_role_webapp companyname_role_dbserver Now. here is the important bit: Each module is a git repo with one or more remotes. If it is a base or a role module, then the remote will be a private repo. If it is a common module then it will have 2 remotes, a private one and the mantainer repo. All modules are tagged. Tags can be different among environments but you should always push forward incremental tags, never backwards. IE: GOOD: dev/common/apache -> tag 1.4 qa/common/apache -> tag 1.2 stg/common/apache -> tag 1.1 prd/common/apache -> tag 1.1 WRONG: dev/common/apache -> tag 1.0 qa/common/apache -> tag 1.3 stg/common/apache -> tag 1.3 prd/common/apache -> tag 1.1 That is a little bit of common sense. You should never push higher tags in more critical environments if they never were tested in the testing environments. Finally with common modules it works something like this: 1- clone the module and create tag 1.0 2- New release by the developer, pull the changes from the remote and create a new tag 1.1 3- push the new tag in dev environment and test it against that. 4- If all is good, promote the tag to the rest of the environments. Hope it make sense, bug if you have any question just let me know Cheers Juan On Wednesday, August 7, 2013 3:18:02 AM UTC+1, Feifei Jia wrote:> > Thanks for the reply, Brian. > > I have looked into librarian-puppet, a good tool, just like ruby bundler. > Will give it a try. > > And I''m also interested in your alternative way to organise your module. > Could you explain more on that? What the modules directory structure look > like? Just like the following? > > /etc/puppet/modules/{library_modules, your_module_a, your_module_z} > > > On Tuesday, August 6, 2013 5:52:12 PM UTC+8, blalor wrote: >> >> On Aug 6, 2013, at 5:27 AM, Feifei Jia <feif...@gmail.com> wrote: >> >> This is very inconvenient, obviously. So how do you guys manage >> third-party modules, except using git submodule? Thanks. >> >> >> I use librarian-puppet https://github.com/rodjek/librarian-puppet for >> one of my projects. It''s basically a dependency management system for >> Puppet modules, a la Maven, Ruby gems, etc. The problem is that I find its >> resolution of versions quite unreliable, for example grabbing apache 0.8.1 >> when 0.6.x is specified. The author is working on a replacement called >> Henson https://github.com/wfarr/henson. >> >> Librarian-puppet has some (undocumented) functionality that looks like >> it''ll allow you to cache your dependencies and work from those, so I''m >> considering looking into that and committing the cardinal version control >> sin of checking in 3rd-party dependencies. For right now, tho, despite my >> concerns with it, I find it a huge improvement over submodules or managing >> others modules in my source. >> >> An alternative may be to separate out your own modules from 3rd-party >> modules. As it is, I put librarian-puppet-managed modules into a >> "library_modules" folder and ones developed just for a given project into >> "modules". That will give you some separation of code and at least make it >> easier to manage updates. >> >> -- >> Brian Lalor >> bla...@bravo5.org >> http://github.com/blalor >> >>-- 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+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.