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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
