> Take "rm" as a trivial example - when I say `rm foo.txt`, I want the file to be gone. What if the file is already gone? Then it throws an error!
Simply rm the file and handle the particular error case of the file existing by ignoring it. Other errors go through fine.
I've been doing this at work to try to wrangle a sense of control out of our various projects. I'm using Sprinkle, which is basically a wrapper around SSH.
What I'm finding is that most decent projects include idempotent ways to configure them. Apache, for instance, at least on Ubuntu allows you to write configs to a directory and then run a command to enable them. Sudo also has the sudo.d directory, cron has cron.d. Just write a file.
> Is there a "don't do anything I didn't explicitly tell you to!" flag for apt-get ?
I would consider this to be overly tight coupling. We should let dpkg manage the OS packages, and if the system's state needs to be changed, you can simply re-build it and run an updated version of your management scripts.
You don't really want to start getting into the game of trying to abstract over the entire domain of systems engineering. CM, in my opinion, should solve one and only one problem, moving system state between the infrastructure/cloud provider defaults and a state where application deployment scripts can take over. Every necessary change to get from point A to point B gets documented in a script. There are only two points on the map, and only one direction to go.
So CM is a provisioning tool? I thought of it as being more of "ensure trusted compute environment" tool. But all the existing tool sets require additional engineering to revert changes that aren't in their dynamically rendered file set.
>Simply rm the file and handle the particular error case of the file existing by ignoring it
How do I differentiate to ignore one error and not others? Matching a string? What if this is supposed to be portable? Hard code strings for every version of rm ever made?
>What I'm finding is that most decent projects include idempotent ways to configure them
Those are modifications debian makes. Lots of software supports including files, which lets debian do that easily. But sudo has nothing to do with you having a sudo.d directory, that is entirely your OS vendor. And having that doesn't solve the problem. What happens when I want to remove X and add Y? You need to have the config be a symlink, so you can do the modifications completely offline, then in a single atomic action make it all live.
Your configuration management is going to have to be OS-dependent. Nothing is going to be so portable that you'll be able to use the same commands on different distros. POSIX is too leaky an abstraction to rely on.
I'm not sure if you are agreeing or disagreeing. Configuration management tools already exist that work across multiple operating systems. You can't rely on posix, but you also can't rely on anything else. There's no standard, sane way to get "what error happened" information from typical unix tools.
Simply rm the file and handle the particular error case of the file existing by ignoring it. Other errors go through fine.
I've been doing this at work to try to wrangle a sense of control out of our various projects. I'm using Sprinkle, which is basically a wrapper around SSH.
What I'm finding is that most decent projects include idempotent ways to configure them. Apache, for instance, at least on Ubuntu allows you to write configs to a directory and then run a command to enable them. Sudo also has the sudo.d directory, cron has cron.d. Just write a file.
> Is there a "don't do anything I didn't explicitly tell you to!" flag for apt-get ?
I would consider this to be overly tight coupling. We should let dpkg manage the OS packages, and if the system's state needs to be changed, you can simply re-build it and run an updated version of your management scripts.
You don't really want to start getting into the game of trying to abstract over the entire domain of systems engineering. CM, in my opinion, should solve one and only one problem, moving system state between the infrastructure/cloud provider defaults and a state where application deployment scripts can take over. Every necessary change to get from point A to point B gets documented in a script. There are only two points on the map, and only one direction to go.