Red Hat Bugzilla – Bug 1470297
Allow "pcs resource enable/disable/restart" take effect immediately (disregarding start-delay, interval-origin operation attributes)
Last modified: 2017-11-30 12:44:30 EST
It's very counterintuitive that start-delay parameter will kick in when
enabling/disabling the resource manually.
I would even suggest that "immediate" mode should be default and honoring
start-delay should be upon request (--no-rush).
Add "pcs resource restart" into the mix ([bug 1469801 comment 6]).
Can you elaborate on what the problem is, provide a reproducer and show what actual and expected behavior is. Thanks.
Per summary, the problem is that start-delay is honored at places it
is against the spirit of the intention of who launches the respective
It's entirely OK, when it is honored
- in the standard run of pacemaker resource management
It's likely OK, when it is honored
- for the resources associated with the resource being enabled/disabled
- non-primitive resources (likely requires further investigation)
It's not OK (IMHO), when it is honored
- pcs resource (enable|disable|restart) <primitive>
If some wait time is required, the user should simply wait on it's own
or prepend "sleep X" to the compound command, any internal implied
delays are (again IMHO) harmful in such case.
I had a look at Pacemaker Explained and it doesn't refer to to start-delay
directly, but announces interval-origin instead, which should likewise be
suppressed in the described scenario: