On 27/11/18 12:29 +0200, Klecho wrote: > Big thanks for the answer, but I in your ways around I don't see a solution > for the following simple case: > > I have a few VMs (VirtualDomain RA) and just want and to stop a few of them, > not all. > > While the first VM is shutting down (target-role=stopped), it starts some > slow update, which could take hours (because of the possible update case, > stop timeout is very big). > > During these hours of update, no other VM can be stopped at all. > > If this isn't avoidable, this could be a quite big flaw, because it blocks > basic functionality.
It looks like having transition "leaves", i.e. particular executive manipulations like stop/start operations, last in order of tens of minutes and longer is not what's pacemaker design had in mind, as opposed ot pushing asychronicity to the extreme (at the cost of complexity of the "orthogonality/non-interference tests", I think). But the shutdown procedure can be shortcircuited with possible HA compromises like this: - put all the VMs you want to stop into an unmananged state (is-managed=false) - trigger the shutdown independently of the cluster mananagement - when they are indeed off (as also indicated by crm_mon if the monitor operation hasn't been disabled), they can be resurrected again when suitable (is-managed=true or dropping that property to designate an equivalent default) can't it? There is a couple of questions, though, like how to make it that the particular VM won't be shut down in a standard way, which would trigger the stated problem again (as mentioned, node shutdown shall be OK). Customizing resource agent to become an active pacemaker observer/influencer beside a purposed notification mechanism and customization through attributes and rules feels terribly flawed. -- Nazdar, Jan (Poki)
pgpX7nXHWcKnM.pgp
Description: PGP signature
_______________________________________________ Users mailing list: [email protected] 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
