Ideas/Best Practices for module versioning

622 views
Skip to first unread message

Marc Zampetti

unread,
Jul 14, 2010, 10:20:56 AM7/14/10
to puppet...@googlegroups.com
All,

We are looking to implement Puppet as part of our config
management/provisioning system. I've read a lot of wiki pages, all the
Puppet docs, and the forums and mailing list archives. So far, I'm
pretty comfortable with most of puppet, but the one area that I am a bit
confused about is how to do node-level module version control.

Basically, one of the key requirements is that I be able to know exactly
which version of a module supposed to be applied to a node. We are not
going to run Puppet in "auto update" mode out of cron, but instead push
changes as part of our config management work-flow. As such, I need to
be able to target a specific version of a module to a specific host, or
group of hosts. I know that using an external node script is probably
the way to go here, and I'm comfortable with that. What I don't know is
how to manage the life-cycle.

For example, I have a module, foo at v1. It uses two other modules, bar
v2, and zoom v3. I apply that to the nodes I care about, and everything
is fine. Then I get updates for foo, and bar. That bumps them to foo v2
and bar v3. But bar is also used by several other modules, and I don't
want to have them affected by the changes to bar yet. I only want to
apply the changes to the specific nodes that need them.

To further complicate all of this, I need to be able to rebuild a
machine quickly. That means that I need to be able to reimage the host,
and have puppet return it to the same exact state as when it died. We
also usually role out changes slowly, updating hosts one at a time in a
group, sometimes letting them "burn in" for a day or so to ensure that
the changes won't have any production impact that we didn't catch in QA
due to things like load, user population, etc. That means that I need to
be careful, since during this "burn in period", I still have to be able
to handle the "reimage the host" problem.

I know about environments, and I see how they might help. I also have
looked at some of the info about using VCS-based options, like using git
or svn or something like that. What I'm mostly looking for is what
others are doing? How have others handled this problem? Are there
solutions I don't know about that I can leverage before I go and build
on my own?

Any insights or help is greatly appreciated.

Ohad Levy

unread,
Jul 14, 2010, 11:19:33 AM7/14/10
to puppet...@googlegroups.com
I use environments for this purpose.

the first step is to add versions to your modules, then to automatically generate an environment for that selection of modules (in their respective version)

hope this helps,
Ohad

--
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...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.


Cosimo Streppone

unread,
Jul 14, 2010, 11:39:40 AM7/14/10
to puppet...@googlegroups.com
On Wed, 14 Jul 2010 17:19:33 +0200, Ohad Levy <ohad...@gmail.com> wrote:

> I use environments for this purpose.
>
> the first step is to add versions to your modules, then
> to automatically generate an environment for that selection of modules
> (in their respective version)

And how do you do that?
Tried searching around for 'puppet module versioning' and the like
but found almost nothing apart a mention of 'we need to do module
versioning'.


--
Cosimo

Ohad Levy

unread,
Jul 14, 2010, 12:21:19 PM7/14/10
to puppet...@googlegroups.com
As puppet modules == code, use your version control system to tag the versions.

I ended up putting all stable tagged modules in a special directory, and each environment contain links to the modules that I want to use (which is defined via a puppet define).

Ohad

Marc Zampetti

unread,
Jul 14, 2010, 12:51:39 PM7/14/10
to puppet...@googlegroups.com
Ohad,

So does that mean you have a large number of environments? Wouldn't this mean that worse case is that you have a separate environment for each node?

Marc

Ohad Levy

unread,
Jul 14, 2010, 11:00:48 PM7/14/10
to puppet...@googlegroups.com
On Thu, Jul 15, 2010 at 12:51 AM, Marc Zampetti <marc.z...@gmail.com> wrote:
Ohad,

So does that mean you have a large number of environments? Wouldn't this mean that worse case is that you have a separate environment for each node?

In theory yes, but we never had this kind of scenario, we currently maintain about 50 environments, and it seems to be stable in the last few years...
Nodes usually migrate from one environment to the other, rather then creating a new environment per node.

Ohad

mohit chawla

unread,
Jul 15, 2010, 1:48:48 AM7/15/10
to puppet...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages