At work, I’ve had the opportunity to look at Cobbler. It’s magical software that makes great ease of repository management and server deployment. It offers the latter by providing a webUI for managing a kickstart server. The result? Your server install experience should be: rack hardware, run cables, work with the network team for appropriate access and then boot the machine. You’ll then be greeted with a kickstart menu to pick the appropriate OS to install. Your kickstart file will run, leaving you wherever it finishes. At some point, we’ll then want to tie the newly built system into configuration management.

For me, I don’t have hostnames or mac addresses automatically generated/harvested. I see these as convenient unique identifiers, that if I had, I could use to automate OS selection and configuration management install. Cobbler works with neither of these. With effort, kickstart could be made to interpret these, but then you’re off building your own infrastructure, nurturing careful pieces of kickstart to work with an external database to appropriately build systems. Automation is our goal, and so building this kickstart-level magic would be a noble effort if ready-built systems are not already in place.

TheForeman is one such system. It is a webUI for provisioning and managing systems, but it does so with one big assumption: puppet. The software is really focused on complete lifecycle management, and it does it well. If you can accept this integration, then our chain is complete: power on a box, give it some time, and then log into a fully configured system. (Though with everything installed and configured, why log in?)

Also available is Razor. This also comes with strings into puppet; literally, as its a joint project from Puppet Labs and EMC. It provides your running puppetmaster a way to instance server creation. It’s all command line, and meant more as an API to automate resource provisioning. This is all well and good; I like tools that do one thing, and do them well. That said, I’m going to let this lie for a little bit. Ultimately my end-goal for automation is a set of buttons I can turn over to non-sysadmins so they can provision new resources without me. Quite a bit of work is needed to leverage Razor for this.

Both these tools are from the puppet camp. I’m ignorant of tools for other configuration management platforms.

The challenge of automated provisioning is keenly felt in the cloud arena. Cloudstack breaks this problem in twain: orchestration and provisioning. My understanding comes from the slides at Alex Huang’s presentation. Orchestration seems to cover all the coordinatingevents to allow a machine to work (storage assignment, network assignments, &c). Provisioning the actual machine seems to be pushed down to the hypervisor. There are accomodations for bare metal machines, so using this as the base of a deploy process is feasible. However, you’re left with your configuration management platform reaching out and using the cloudstack API.

There’s more research to be done here, obviously; but I wanted to get my understanding down. As well, there doesn’t seem to be much discussion about specific tools for this need. I’m left to believe each cloud platform and each configuration management product is doing it all for itself. That’s a shame, as it doesn’t allow for interoperability or code reuse.