Here’s a few paragraphs of my thoughts about Functional Operations. By Functional Operations I mean that which emerges out of the meeting of “golden images” (delicately crafted base images that once deployed need config management) and “config management” (the config data and rules for applying it to a live golden image.)
As the “golden” image itself becomes integrated into the config management, it changes just like any other variable in the config management database. What’s changed in our toolkit? What benefits do we get?
One thing we surely get is tracked versions. Let’s see what other things are already versioned – no matter where we keep them:
* Applications: e.g. Apache 1.3.12
* Software Packages of Applications: apache-1.3.12_ubuntu1.deb
* Config Files: httpd.conf patch=SHA
* Variables in config files: listen: :
If your network management system is amazing you also have
* network configurations: cisco_pix_3.txt patch=SHA
But hopefully at least your network admins have your
* switch configs under version control (e.g. as above)
* data store: mount -t qcow /images/my_bits.qcow
Your other storage itself might be Copy On Write (cow) or you database has transaction logs.
The Disk Image
The golden image is an object. It is made up of the “variables” above, and the “methods” that is their interprocessing as processes and threads. The interaction of processes happens in the field of the operating system.
Partial and Full Virtualization were implemented thanks to their various hypervisors. And thanks to them, we can snapshot states of whole OSes, containers and even single processes. We gather up their RAM, process IDs, storage, etc and store them away as snapshots. But we don’t have a way of moving through those snapshots in a meaningful way.
Tools like Chef finally create objects out of the stuff of our OS. But what of making an object of objects? How can we best understand their interactions? We can start up an os and alter it through its lifecycle, and take snapshots of certain holiday adventures we really treasure. But we have very little certainty that the service we seek to restore to going back to those snapshots will give us the total service state we desire. I do do this pattern sometimes, but it feels safe because I fully understand the interactions between the processes, and I choose my holiday snapshot time accordingly.
What I want to do is take Chef resources the objects I detailed above and manage their states, creating an emergent service readiness interaction language. I can surmise basic hardware qualities necessary for my service, and have these bits of Chef code entice the service to emerge.
Finally, the reality and sustaining fitness of a service requires well curated sets of consensus parameters and the power of each actor to participate in effecting that consensus through code.
That, to me, is Crowbar.