# Managing configuration versions

Craig Dunn has suggested using roles and profiles in combination with versions of "dev" and "live", for example. But this only accommodates a system under development and a system deployed to production, respectively. However, this method does not allow a specific version to be utilized within a development phase.

Can Puppet be utilized to provide multiple versions of a configuration? For example, rather than "dev" and "live" I would like to be able to configure a system with version 1134 or version 1150.

Thanks, Brian

edit retag close merge delete

Sort by » oldest newest most voted

Yes.

Specifically, I use https://github.com/Yelp/puppetupdate so that the thing that goes to puppetmasters is the latest version of 'master' which has passed the tests etc.

I.e. Jenkins has a 'run syntax' job which fires on commit. This saves the exact SHA, and passes it to 'run tests' (which then checkout and test that SHA), if that works, then we (by which I mean Jenkins) deploys exactly that SHA to puppetmasters.

You can get more complex than this easily if you need to, with many stages code passes through, and automatic or manual steps to 'promote' the working code nearer to 'production' :)

The only real challenge is defining what you want the workflow to look like for your organisation, the technical parts of doing that then have a whole bunch of easy to steal prior art.

Feel free to ask more (more questions, that are more specific) about the actual thing you're planning if you'd like concrete advice.

more

We develop and host custom solutions. Each solution has a different release schedule. Some have regular releases, others have infrequent releases, and others rarely have releases. Evolving general modules is challenging as incompatibilities may be introduced. Good development practices may help.

( 2014-04-27 16:14:52 -0600 )edit

One approach would be to use a dynamic mechanism to identify the scripts that align with a particular solution. The goal of the effort is to limit the possibility of errors introduced through changes. Good development practices will help, but I would like something more effective.

( 2014-04-27 16:21:25 -0600 )edit

Doing this in a completely dynamic fashion would be challenging. If you are hoping to do something along the lines of

puppet agent --onetime --no-daemonize --version=1150


then you're quite likely stumped.

A compromise would be to create semi-dynamic environments for each revision that may be desirable for a known group of agents, so that you can then

puppet agent --onetime --no-daemonize --env=r1150


You can make this more flexible using directory environments on a 3.5 or later master.

more

Thank you ffrank! I will have to examine this option as I didn't know about directory environments.

( 2014-04-27 16:22:17 -0600 )edit