[ClusterLabs] New cluster.target to control cluster services
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
Re: [ClusterLabs] Too quick node reboot leads to failed corosync assert on other node(s)
On 02/18/2016 10:40 AM, Christine Caulfield wrote: > I definitely remember looking into this, or something very like it, ages > ago. I can't find anything in the commit logs for either corosync or > cman that looks relevant though. If you're seeing it on recent builds > then it's obviously still a problem anyway and we ought to look into it! Thanks for you replies. So far this happened only once and we've done only "post mortem", alas no available reproducer. If I have time, I'll try to reproduce it locally and check whether it exists in the current version. Michal signature.asc Description: OpenPGP digital signature ___ Users mailing list: Users@clusterlabs.org http://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
Re: [ClusterLabs] Parallel adding of resources
On 01/08/2016 04:35 PM, Ken Gaillot wrote: > While pacemaker will of course initiate the moves one by one, it > shouldn't wait for one to be completed before initiating the next one, > unless you have ordering constraints between them or they are in a group > together. Or execution of actions may be subject to throttling of parallel actions running (see node-action-limit cluster property). Michal ___ Users mailing list: Users@clusterlabs.org http://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
