I've long suspected that something like this was the logical end point. Ever since I found myself writing a Puppet manifest that created an Upstart entry.
Configuration engines have tended to emphasise bits-at-rest. "Make sure these packages are installed, that these files are present, that this is what's in /etc".
Process management engines emphasise bits-in-flight. "Make sure Wordpress is running. Wordpress relies on PHP, nginx and MySQL".
Generally speaking, config engines assume that the bits-at-rest are correctly arranged to ensure correct runtime performance. And process management assumes that someone else has supplied the bits-at-rest which can be reified into an operational system.
Configuration engines tend to stray a bit into ensuring that software is up and running (eg, cfengine polls services every 5 minutes), but stop well short of the final conclusion of process management: insertion into the init hierarchy.
Why the separation? It's historical. Each local problem was solved in isolation (broken server config / crashing server processes) and they've each grown at the edges towards each other.
Just as ZFS collapsed several historical layers of file system tools into a single layer, it's been long overdue for the concept of defining a model of a system's various configurations with a detect-and-correct mechanism to be a universal framework that applies across an entire system.
Don't let the XML configuration put you off. I suspect they'd have used JSON if they were doing it again, but it's from the era when XML was the default structured text based format.
It follows a similar philosophy to Nix but for runtime management of processes and events in general. It's really functional though. But it is a bit declarative, with the implicit backtracking, the unique feature of NCD.
Configuration engines have tended to emphasise bits-at-rest. "Make sure these packages are installed, that these files are present, that this is what's in /etc".
Process management engines emphasise bits-in-flight. "Make sure Wordpress is running. Wordpress relies on PHP, nginx and MySQL".
Generally speaking, config engines assume that the bits-at-rest are correctly arranged to ensure correct runtime performance. And process management assumes that someone else has supplied the bits-at-rest which can be reified into an operational system.
Configuration engines tend to stray a bit into ensuring that software is up and running (eg, cfengine polls services every 5 minutes), but stop well short of the final conclusion of process management: insertion into the init hierarchy.
Why the separation? It's historical. Each local problem was solved in isolation (broken server config / crashing server processes) and they've each grown at the edges towards each other.
Just as ZFS collapsed several historical layers of file system tools into a single layer, it's been long overdue for the concept of defining a model of a system's various configurations with a detect-and-correct mechanism to be a universal framework that applies across an entire system.