[ClusterLabs Developers] Notify actions

[Ken Gaillot]

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 <kgaillot at redhat.com>