[ClusterLabs] Antw: [EXT] Re: [Problem] In RHEL8.4beta, pgsql resource control fails.

[Ulrich Windl]

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 28.04.2021 um 19:00 in
Nachricht
<e3ed5c7619254da8ed509cb5cdec835d3e7bb686.camel at redhat.com>:
> On Wed, 2021‑04‑28 at 18:14 +0200, Jehan‑Guillaume de Rorthais wrote:
>> Hi all,
>> 
>> It seems to me the concern raised by Ulrich hasn't been discussed:
>> 
>> On Wed, 12 Apr 2021 Ulrich Windl wrote:
>> 
>> > Personally I think an RA calling crm_mon is inherently broken: Will
>> > it ever
>> > pass ocf‑tester?
> 
> Calling the command‑line tools in an agent can be OK in some cases. The
> main concerns are:
> 
> * Time‑of‑check/time‑of‑use: cluster status can change immediately, so
> the agent should behave reasonably if a query result is incorrect at
> the moment it's used. Ideally there would be no case where the agent
> could incorrectly report success for an action.
> 
> * No commands that *change* the configuration (other than setting node
> attributes) should ever be used. Otherwise there's a potential for an
> infinite loop between the agent and scheduler.
> 
> * It's best to use tools' XML output when available, because that
> should be stable across Pacemaker releases, while the text output may
> not be. Aside from crm_mon, XML output is a recent addition, so some
> consideration must be given to backward compatibility and/or requiring
> a minimum Pacemaker version.
> 
> * Only the configuration section of the CIB has a guaranteed schema.
> The status section can theoretically change from release to release,
> although in practice it has changed very little over the years.

I think you missed one important point (I would never do it, but who knows):
* At most query the status of the own resource. (i.e.: Don't query the status
of other resources to make decisions)


> 
> I don't use ocf‑tester so I can't speak to that, but I suspect it could
> work if you exported a CIB_file variable with a sample cluster status
> beforehand. (CIB_file makes the cluster commands act as if the
> specified file is the live CIB at the moment.)

The thing is that unless using -L, the RA runs without an actual cluster, so
any cluster queries will return nonsense at best.

Regards,
Ulrich

> 
>> Would it be possible to rely on the following command ?
>> 
>>   cibadmin ‑‑query ‑‑xpath "//status/node_state[@join='member']" | \
>>     grep ‑Po 'uname="\K[^"]+'
>> 
>> 
>> Regards,
> 
> Only full cluster nodes will have a "join" attribute, so that query
> won't catch active remote nodes or guest nodes. Whether that's good or
> bad depends on what you're looking for.
> 
> The plus side is that it's a query and it returns XML.
> 
> The downsides are that node status can change quickly, so it could
> theoretically be inaccurate a moment later when you use it, and the
> status section is not guaranteed to stay in that format (though I
> expect that particular part will).
> 
> A minor point: that query will return the entire node_state XML
> subtree; you can add ‑n/‑‑no‑children to return just the node_state
> element itself.
> ‑‑ 
> Ken Gaillot <kgaillot at redhat.com>
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> 
> ClusterLabs home: https://www.clusterlabs.org/