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.zampe...@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-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
