I am not interested in a philosophical discussion because I do not want to argue. I want to compare and demonstrate. Let the code speak.

You don’t have to argue with me, just give me a file and let me demonstrate my way, then do (or not) what you want after that. I still think you do not understand what I am talking about, and I think that because you mention things like “SmartOS is a hypervisor” — we all know that. It has been beaten to death enough times. It’s a hypervisor. It’s not perfect, but it’s the best. That’s not the issue.

And I’m not a troll; all I am asking you to do is provide a simple configuration file, and I can demonstrate.

As you can imagine, I have a huge problem with a daemon arbitrarily overwriting a set of files it has been told to watch over, because to me, that means someone has logged onto the system and changed something manually. And that in turn signals that process is deficient.

In my view, other than to perhaps setup storage, nobody should ever be allowed to log into a system for any reason, let alone hack any files by hand so that a solution like Chef would have to overwrite them. That means that somework should have been packaged and it was not, or that some framework that a component could call needed to be designed and was not.

Solutions like Chef and Puppet are treatments for a symptom, not a cure for the root cause. That is my experience anyway.

Now, if I missed anything, feel free to correct me.

Please give me a configuration file, and tell me what it needs to look after the fact. I will implement each and every point you made in a package. Then feel free to rip me apart if you still think what I did is incorrect and will not scale.

I think that you and I want the same thing, but that we are speaking about completely different things, and want to get that out of the way first. What do you say?

On to Configuration Management (CM) versus configuration rolled into packaging. This is not a new or unique conversion, in fact it was hotly debated at DevOps Days Mountain View in 2010 (pretty sure it was 2010). Some people we packaging their configuration up and overlaying it as a version controlled RPM/Deb, there were others who were adding them to packages as pre-/post- install scripts. The debate was fierce. Some people felt, as you obviously do, that the software and the configuration were inextricably linked and therefore should be managed as a single asset. Others felt, as I do, that the systems configuration should be entirely independent of the packaging system so that it was both portable and consistent. There are advantages and disadvantages to both approaches. Package based configuration is extremely precise however it is also extremely inflexible. If your managing a medical device (several do) the consistency is extremely important and flexibility isn’t. However, if your deploying a web service on Joyent and then wish to deploy a cold standby on SoftLayer, flexibility is of prime importance. So lets be clear, the choice you make depends on the problem your solving.

You clearly have a very old and primitive view of Configuration Management, which is not uncommon. That is, you see it as little more than a hodge podge of shell scripts in a specialty language not worth your time to learn. Many have felt this way… “I can do all this in a bash script, screw Puppet” or the like.

The power of CM is in its consistency, idempotence, and versatility. With Chef, for instance, attributes can be applied to a server or group of servers to tailor a single generic cookbook for the task at hand. I have different Zabbix servers in each of my data centers, but I use a single cookbook for all of them, I just change the “zabbix/server” attribute as appropriate and I’m done. More importantly, I can change that configuration in seconds by simply updating the attribute file and having Chef re-run. If that configuration was in a package I’d have a heart attack reinstalling or updating the zabbix-client package.

Keep in mind the type of automation your preforming. If its just adding a user for a daemon, sure that goes in the package post-install…. if your configuring which of 10 different syslog aggregators it should point to, that’s not so easy.

Finally, keep in mind that CM is and should be idempotent. That is, you can re-run it over and over and it will preform not function unless it needs to be done. For instance, if a config file already matches the configuration I want, it does nothing, otehrwise it makes it (declarative) right. Therefore, if I want to ensure everything in my datacenter is configured properly I just let my CM tool run and if everything is good, nothing happens, if anything is wrong, it fixes it. This is something you CAN NOT DO in a Jumpstarted environment. Trust me, I had a world class Jumpstart infrastructure for a very long time… everything was perfect when deployed, but after 6 months validating that things hadn’t drifted was nearly impossible and fixing anything that had changed was a daunting task.

If that doesn’t convince you I don’t know what else to day. CM isn’t the future any more, its the present accepted standard. Those who haven’t moved to CM are now at least 2 years behind the curve. CM is industry standard in all but legacy environments and many of those will back fill it simply for sanity sake in the future.