Levels of automation

First level

A script that dumbly all the commands that were identified to be "right"

apt-get install git-core etckeeper
etckeeper init
#EOF

 

Second level

A script that runs them and handles errors

apt-get -y install git-core etckeeper &&
etckeeper init

Most people reach the point of doing "kit checks", like testing if the apt repository is configured.

The thing which seems harder is: Ideally the script dies in a defined way, leaving no corrupt state - and many people never learn that.

 

Third level

A script that runs those commands only if needed

for pkg in git-core etckeeper ; do
    type $pkg > /dev/null || apt-get install $pkg
done
if ! [ -d /etc/.git ]; then
    etckeeper init
fi

 

 

Forth level

An automation framework that lets you express the target states and a "runbook" order.

If your syntax lets you express things like "state: installed", you're good!

But, even better if you can express:  "if this changed", do something because of the change.

So the tool doesn't just bring along idempotency, but also knows about state transitions.

The problem here is the pretty strict interdependency of changes.

 

The fifth level:

 

Express the same "I would this like to be installed" but let the configuration system converge to the state.

 

So, if you have many such requests, you do not express it as "do this then that, and finally that". 

Instead you write it as:

  • I would like this to be installed
  • I would like this other thing to be installed
  • If condition A is newly met, I would like you to make sure this will be run.
  • If condition A is newly met, I would like you to make sure this other thing be run.
  • If condition B is not met, I would like you to make sure this 3rd thing will be run.

The difference is that each component can be independently strive to get to an OK state, thus *converging* towards the desired overall state.

As far as a single node is concerned this is pretty perfect.

The tool needs to be able to know the states, recognize state changes and also the last-recent state.

 

In human terms, it's not like talking to an untrained help you need to teach every single step to replace your car's tires. Instead, it's more like you would talk to a maintenance expert hired just for your car pool?

"Can you check up the cars every few weeks?"

 

 

 

The sixth level

Be able to natively express cross-network dependencies.

"Run the changes on as many nodes as the SLA goals for uptime and performance allow".

Understand and respect group quorums.

This is something for the future -

a) tools that tackle what CM people currently still consider "nasty problems"

b) overcome temptation to limit cross-host features as commercial-license only features
(mostly since those issues need to be researched and won't be solved well by *one* project looking into them)


  • No labels