Puppet users - Jul 2010 - Ideas/Best Practices for module versioning

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.

-- 
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 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
On Wed, Jul 14, 2010 at 10:20 PM, Marc Zampetti
<marc.zampetti@gmail.com>wrote:
>  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.
>
> --
> 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.
>
>
-- 
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 Wed, 14 Jul 2010 17:19:33 +0200, Ohad Levy <ohadlevy@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

-- 
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 Wed, Jul 14, 2010 at 11:39 PM, Cosimo Streppone
<cosimo@streppone.it>wrote:
> On Wed, 14 Jul 2010 17:19:33 +0200, Ohad Levy <ohadlevy@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''.
>
> 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

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

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

On 7/14/10 12:21 PM, Ohad Levy wrote:
>
>
> On Wed, Jul 14, 2010 at 11:39 PM, Cosimo Streppone 
> <cosimo@streppone.it <mailto:cosimo@streppone.it>> wrote:
>
>     On Wed, 14 Jul 2010 17:19:33 +0200, Ohad Levy <ohadlevy@gmail.com
>     <mailto:ohadlevy@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''.
>
> 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
>
> -- 
> 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.
-- 
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 Thu, Jul 15, 2010 at 12:51 AM, Marc Zampetti
<marc.zampetti@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

Marc
>
>
> On 7/14/10 12:21 PM, Ohad Levy wrote:
>
>
>
> On Wed, Jul 14, 2010 at 11:39 PM, Cosimo Streppone
<cosimo@streppone.it>wrote:
>
>> On Wed, 14 Jul 2010 17:19:33 +0200, Ohad Levy
<ohadlevy@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''.
>>
>>  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
>
> --
> 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.
>
>  --
> 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.
>
-- 
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.

This article is quite helpful as well:

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control



On Thu, Jul 15, 2010 at 8:30 AM, Ohad Levy <ohadlevy@gmail.com> wrote:
> On Thu, Jul 15, 2010 at 12:51 AM, Marc Zampetti
<marc.zampetti@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
>
> Marc
>>
>>
>> On 7/14/10 12:21 PM, Ohad Levy wrote:
>>
>>
>>
>> On Wed, Jul 14, 2010 at 11:39 PM, Cosimo Streppone
<cosimo@streppone.it>wrote:
>>
>>> On Wed, 14 Jul 2010 17:19:33 +0200, Ohad Levy
<ohadlevy@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''.
>>>
>>>  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
>>
>> --
>> 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.
>>
>>  --
>> 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.
>>
>
>  --
> 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.
>
-- 
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.