How to structure puppet control

[Tim Coote]

Hullo

I've been a casual puppet user for some time and I'm struggling with the different lifespans and innovation rates of the different components in my environment. In order to trial new distro versions with new puppet clients, I need my puppet master to be on a newish distro, and probably provisioned on a vm to keep me honest in not making local changes.  So how do I create that puppetmaster? 

My initial thought was to bootstrap from a low rate of change computer with an old version of puppet on it and then pull in the puppet configuration for the vm based puppetmaster from some revision control system.  The machine with the old distro version is a physical box that actually hosts most of my vms, too.

However, the documentation implies to me that this is not an expected usecase.  Am I correct? Should I be managing the vm puppetmaster as a 'standalone deployment' and including its configuration in the revision control environment, which increases the work in the vm launching process (I'm using cobbler for launching vms, which seems ok with chained service masters).

I don't want to fight the design of puppet if it's not intended to be used how I'd envisioned.

Advice welcome.

Tim

[jamese]

It can be fiddly to get puppet to manage it's own master, but if you write your manifest so that you can use it with "puppet apply" then you can bootstrap your master from the same code you use to keep the master config in place when its live.  Just remember to back up the /var/lib/puppet/ssl/ca directory if you don't want to resign all your clients if you nuke the master and rebuild it.