[ClusterLabs] New cluster.target to control cluster services

[Michal Koutný]

Hello,
I'd like to collect some feedback regarding $SUBJECT.

The current state of the main cluster services and their dependencies
condenses into the following administrative commands:

Enable cluster services:
systemctl enable \
  pacemaker [sbd] [dlm]

Starting cluster:
systemctl start pacemaker

Stopping cluster (all cluster services):
systemctl stop corosync

It's not a great drawback but the asymmetric control is rather
counter-intuitive and IMO it unnecessarily leaks the internal
dependencies to the administrator.

I was thus thinking about the change below (I included only requirement
dependencies, not orderings):

 # pacemaker.service
 [Unit]
 Requires=corosync.service
+PartOf=cluster.target

 [Install]
-WantedBy=multi-user.target


# corosync.service
 [Unit]
+PartOf=cluster.target
 [Install]
 WantedBy=multi-user.target


# sbd.service
 [Unit]
-PartOf=corosync.service
+PartOf=cluster.target
 RefuseManualStop=true
 RefuseManualStart=true
 [Install]
 RequiredBy=corosync.service
 RequiredBy=pacemaker.service
 RequiredBy=dlm.service


# dlm.service
 [Unit]
 Requires=corosync.service
 [Install]
-WantedBy=multi-user.target
+WantedBy=cluster.target


# cluster.target
+[Unit]
+Wants=pacemaker.service
+[Install]
+WantedBy=multi-user.target

The resulting control interface would be then more homogenous:

Enable cluster service:
systemctl enable \
  cluster.target [sbd] [dlm]

Starting cluster:
systemctl start cluster.target

Stopping cluster:
systemctl stop cluster.target


I'm aware that there are crms/pcs commands providing the similar common
control interface.

Do you have any use cases that would benefit from the cluster.target?
What drawbacks do you see if the common cluster.target was used?

Thanks,
Michal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20181022/4004d5cc/attachment.sig>