On Wed, 2020-02-12 at 16:03 +0100, Jehan-Guillaume de Rorthais wrote: > Hello devs, > > I have a few questions about notify action. > > 1. notify clone option > > Why a clone option exist to enable or disable them, and why is it > false by > default?
Most likely to preserve backward-compatible behavior when notifications were first implemented. > As notify is an action, I suppose it should be enabled by default if > the RA > claim to support it in its meta-data action. No need a clone option > for this. > > Moreover, if one need to deactivate it for some reason, I suppose the > proper > way to do it would be to set "enable=false" as the notify operation > property > for the given resource. That would have been a better design. :) I'm not sure whether that would work currently. > What feature would we loose if this clone option is deprecated? As long as we support enable=false, I wouldn't be opposed to deprecating it and removing it "eventually". > 2. return code > > Why the return code from notify is ignored from the cluster? > > As discussed on IRC and by emails (IIRC), > OCF_RESKEY_CRM_meta_notify_* are > available during notify action. These informations are useful for > clones or > promotable resources to detect some wrong actions and raise an error > so the > cluster try another transition. I'm not sure, but I'm guessing one issue is that notifications are called before and after stop. If a stop-related notify failed, the node would likely have to be fenced, just as if the stop itself failed. But unlike stop, notify could support (and default to) on-fail=ignore, so maybe this is an acceptable limitation. > Because of this, in PAF RA, we trigger an error in next expected > action based > on decision taken during the notify action. > > Thoughts? > > Regards, -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/
