>>> Klaus Wenninger <kwenn...@redhat.com> schrieb am 30.03.2021 um 07:32 in Nachricht <9541d96d-be98-15e4-a8eb-966d2ee0f...@redhat.com>: > On 3/29/21 8:44 AM, d tbsky wrote: >> Reid Wahl <nw...@redhat.com> >>> An order constraint set with kind=Serialize (which is mentioned in the first > reply to the thread you linked) seems like the most logical option to me. You > could serialize a set of resource sets, where each inner set contains a > VirtualDomain resource and an ocf:heartbeat:Delay resource. >>> >>> 5.3.1. Ordering Properties > (https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacema
> ker_Explained/index.html#idm46061192464416) >>> 5.6. Ordering Sets of Resources > (https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacema > ker_Explained/index.html#s-resource-sets-ordering) >> thanks a lot! I don't know there is an official RA acting as >> delay. that's interesting and useful to me. I was wondering, too: If pacemaker had a kind of semaphore (as a resource) and you could "enlist" the operations of a resource for such a semaphore, then those operations could be serialized (semaphore initialized to 1) or cuncurrency-limited (semaphore initalized to n > 1). The operation would then wait for the semaphore before starting, and post the semaphore when finished. If you really want delays instead of rate-limits, a similar concept would work: Again use a two semaphores (requests, events) and initialize both to zero. Then any one wanting to request an operation would post the requests semaphore and wait on the events semaphore. Some new resource "event provider" would wait for the requests and post to events, either after some fixed delay, some random distribution, or whatever... But we are getting away from classic cluster then. > In this case it might be useful not to wait some defined time > hoping startup of the VM would have gone far enough that > the IO load has already decayed enough. > What about a resource that checks for something running > inside the VM that indicates that startup has completed? I guess once a domain is consuming significant CPU, it's running. One could also check for virtual disk writes; those will happen typically after initrd has finished, but beware if boot hangs on error... Regards, Ulrich > Don't remember if the VirtualDomain RA might already > have such a probe possibility. > > Klaus >> _______________________________________________ >> Manage your subscription: >> https://lists.clusterlabs.org/mailman/listinfo/users >> >> ClusterLabs home: https://www.clusterlabs.org/ > > _______________________________________________ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
