[ClusterLabs] Fwd: Postgres pacemaker cluster failure

[Ken Gaillot]

On Thu, 2019-05-16 at 10:20 +0200, Jehan-Guillaume de Rorthais wrote:
> On Wed, 15 May 2019 16:53:48 -0500
> Ken Gaillot <kgaillot at redhat.com> wrote:
> 
> > On Wed, 2019-05-15 at 11:50 +0200, Jehan-Guillaume de Rorthais
> > wrote:
> > > On Mon, 29 Apr 2019 19:59:49 +0300
> > > Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> > >   
> > > > 29.04.2019 18:05, Ken Gaillot пишет:  
> > > > > >    
> > > > > > > Why does not it check OCF_RESKEY_CRM_meta_notify?    
> > > > > > 
> > > > > > I was just not aware of this env variable. Sadly, it is not
> > > > > > documented
> > > > > > anywhere :(    
> > > > > 
> > > > > It's not a Pacemaker-created value like the other notify
> > > > > variables --
> > > > > all user-specified meta-attributes are passed that way. We do
> > > > > need to
> > > > > document that.    
> > > > 
> > > > OCF_RESKEY_CRM_meta_notify is passed also when "notify" meta-
> > > > attribute
> > > > is *not* specified, as well as a couple of others. But not
> > > > all   
> > 
> > Hopefully in that case it's passed as false? I vaguely remember
> > some
> > case where clone attributes were mistakenly passed to non-clone
> > resources, but I think notify is always accurate for clone
> > resources.
> 
> [1]
> 
> > > > possible
> > > > attributes. And some OCF_RESKEY_CRM_meta_* variables that are
> > > > passed do
> > > > not correspond to any user settable and documented meta-
> > > > attribute,
> > > > like
> > > > OCF_RESKEY_CRM_meta_clone.  
> > > 
> > > Sorry guys, now I am confused.  
> > 
> > A well-known side effect of pacemaker ;)
> > 
> > > Is it safe or not to use OCF_RESKEY_CRM_meta_notify? You both
> > > doesn't
> > > seem to
> > > agree where it comes from. Is it only a non expected side effect
> > > or
> > > is it safe
> > > and stable code path in Pacemaker we can rely on?  
> > 
> > It's reliable. All user-specified meta-attributes end up as
> > environment
> > variables 
> 
> OK...
> 
> > -- it's just meta-attributes that *aren't* specified by the
> > user that may or may not show up
> 
> OK...
> 
> > (but hopefully with the correct value).
> 
> And that's where I am now loosing some confidence about this
> environment vars :)
> "Hopefully" and "I think is accurate" ([1]) are quite scary to me :/

It looks perfectly reliable to me :) but Andrei's comments make me want
more information.

If I understand correctly, he's saying that the presence of the notify
variable is unreliable. That's fine if the option is not specified by
the user, and the variable is either not present or present as false.
But it would indicate a bug if the variable is not present when the
option *is* specified by the user, or if the variable is present as
true when the option is not specified by the user.

Personally I'd rely on it.

The controller gets the environment variable values from the
<attributes> entries in the scheduler's result. We have numerous
examples in the scheduler regression test data, typically installed
under /usr/share/pacemaker/tests in scheduler/*.exp (for 2.0) or
pengine/test10/*.exp (for 1.1).
-- 
Ken Gaillot <kgaillot at redhat.com>