Testing cdist⚓

Writing my previous rant Stop YAML abuse and IT cruelty and the necessity to install a new server, I took the opportunity to learn cdist “an alternative to other configuration management systems”.

Ansible⚓

In late 2012, following bleader advise, I started learning Ansible.

At the time it was still a young promising project, with some downsides, but the community was growing.

I spend some time using it for myself and in my different jobs, wrote Python plugins for it, watched with great interest plugins such as Mitogen solving one of the big downsides of Ansible (even after years of improvements, is it still painfully slow).

But I increasingly raged against the YAML tricks and workarounds, breaking changes in the syntax, requirements on the target host and the sudden drop of pull-requests acceptance… Soon after it was bought by RedHat.

Sometimes I was spending more time trying to make a role work than I would I done manually…

In short, my frustration increased and it started to cause more headaches than it was solving.

CFEngine⚓

2012 was also the year I was introduced to CFEngine by convinced advocates 1.

The philosophy and uses cases were different and I even worked hard to configure my personal servers with it.

Alas, I was soon taken aback by bugs, known and referenced with years of history in their bug tracker with occasional bumps and the documentation not even warning about them and how to avoid them (at least if you don’t fix them, document them!).

Unaddressed bugs, refused merge requests, documentation being wrong…

CFEngine is a really good software, but only if you use it in the really little uses cases it is sold for…

More…⚓

On my side I tried other solutions, such as Chef, puppet or SaltStack…

I was most impressed by mgmt that I discovered during the FOSDEM 2019 but haven’t still seriously used yet.

Note

Fun fact, James Shubin was also a Puppet contributor.

Both him and Nico Schottelius made their configuration software after frustrations as enlighted Puppet users and developpers 2.

Both of them choose different approach to tackle, in my opinion, different use cases.

And now cdist⚓

I’m still learning, so my opinion could change later.

My first impression is that cdist is not the definite answer for all uses cases; but, as a configuration management tool using a push model, it is quite good.

At least it does not have requirements on the targets other than a POSIX compliant shell, SSH for the transport and to connect directly as the root user.

The latter point is known and assumed 3 and, I must say, I’m not too found about this design decision (^_^)!

Anyway, I will describe here a few concepts which were counter-intuitive for me at first.

cdist design⚓

I’m oversimplifying here, but it might be a good quick start for a newbie.

  1. cidst is written in Python (on the “pushing” side) and POSIX shell.

  2. It’s “manifest” and “types”, which define what you want to happen on your targets, can be written in any languages as long as they follow the expected format

  3. The manifest and __types are executed locally, on the master node; so they can make use on things that are not available on the target nodes.

  4. Even if your scripts are written in shell, in which the code is executed sequentially, the order of execution will not be sequential and especially not necessarily in the order you wrote your actions!

    cdist is smart and will make a dependency graph (the following merge request shows well how it work) and parallelize what can be (but you can work around it).