Gao,Yan

> > The metadata is going to be provided from another CLI like `crm_resource --list-options fencing --output-as xml` > > Since which version? It'll be in 2.1.8 and 3.0.0. And...

Delaying fencing actions targeting the nodes that are hosting more significant resources or resource instances (promoted) to make them win fencing matches has been an very interesting topic indeed for...

Probably somehow let fencer check the cluster status and calculate the delay only when fencing is actually requested?

> We already have a "priority" meta-attribute for resources -- maybe it could be involved somehow. Instead of a per-resource fencing-delay, maybe a cluster-wide priority-fencing-delay that would get applied to...

> > Probably somehow let fencer check the cluster status and calculate the delay only when fencing is actually requested? > > Up to now we've tried to avoid the...

> > A simpler rule of course could be "promoted instances only take a little higher priority (+0.000001) than the base priority on calculation, not higher than any other resources...

And again a question is, should fencer combine `priority-fencing-delay` with `pcmk_delay_base/max`, or should it just pick the longest among them as the actual delay?

> My main-idea was keeping systemd specifics out of the C-codebase/dependency. I think so too. It's not for sbd to understand what mechanism starts its daemon. > What I see...

> > I haven't figured out a way either. OTOH, I don't think it's for the binary to care about systemd settings as mentioned :-) > > I would have...

Indeed putting the checking parts into a library, and systemd-specific things even into a separate library would be beneficial for implementing a pre-start in C. I might be misunderstanding anything...