Comment 3 for bug 829412

Clusterings is a tough one. I think the big issue here is that clustered services like DRBD and pacemaker are not services that neatly fit into the Ensemble paradigm.

A DRBD master and slave each grab a local block device and expose a service to each other (Replication). This is straight forward via ensemble. But then how does a service like mysql, rabbitmq, etc make use of the new DRBD master? It must be deployed locally to the DRBD master (within the same namespace/container/unit). The upper-level replicated service must also be aware of how the new DRBD device is formated, mounted, as wel as the internal state of the DRBD resource.

For Pacemaker and other cluster stacks and gets more complicated. You would deploy a number of Pacemaker cluster nodes that would presumably relate to one another as peers. You would deploy DRBD "into" this new Pacemaker service such that it gets installed on every node and each DRBD service unit could potentially run on any of the pacemaker nodes (Pacemaker determines when/where). Similarly, you would deploy rabbitmq "into" the cluster, it is also capable of running on any cluster peer. Pacemaker's internal dependency configuration would ensure it only runs on the DRBD master node and only after the DRBD service is in a good state.

In all cases and up-and-down the clustered stack, there is a tight coupling between the hardware, OS, service and environment.

I personally don't see how an setup like this can be expressed via formulas, and would probably need to be implemented in Ensemble itself. At any point, the cluster stack may chose to move services to different nodes, terminate machines, etc. and without any knowledge of the clustered environment, Ensembles view of the world is invalid.

One option/work around would be to leave the HA clustering of specific services to someone/something else and rely on it as an external resource (bug #829420)