FAQ
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.

Search Discussions

  • Brian Lalor at Aug 6, 2013 at 9:52 am

    On Aug 6, 2013, at 5:27 AM, Feifei Jia 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.
  • Feifei Jia at Aug 7, 2013 at 2:18 am
    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.
  • JuanBrein at Aug 7, 2013 at 1:33 pm
    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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedAug 6, '13 at 9:28a
activeAug 7, '13 at 1:33p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase