Ask Your Question

Managing configuration versions

asked 2014-04-25 21:41:44 -0500

bkeyser gravatar image

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 flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2014-04-26 09:35:32 -0500

t0m gravatar image


Specifically, I use 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.

edit flag offensive delete link 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.

bkeyser gravatar imagebkeyser ( 2014-04-27 16:14:52 -0500 )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.

bkeyser gravatar imagebkeyser ( 2014-04-27 16:21:25 -0500 )edit

answered 2014-04-27 13:19:10 -0500

ffrank gravatar image

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.

edit flag offensive delete link more


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

bkeyser gravatar imagebkeyser ( 2014-04-27 16:22:17 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2014-04-25 21:41:44 -0500

Seen: 53 times

Last updated: Apr 27 '14