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

[Ken Gaillot]

On Thu, 2021-04-29 at 09:14 +0200, Ulrich Windl wrote:
> > > > 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.

That's what CIB_file is for. We use it in some regression testing for
similar purposes.

E.g. save a snapshot of a live CIB to a file, then export
CIB_file=/path/to/that/snapshot. Any command-line tools you run after
that will pull the CIB from there rather than from the live CIB.

Of course, some tools need other components of the cluster besides the
CIB, so not everything can work with just that. And the file won't
update status like a live cluster CIB will, so if the agent is looking
for certain changes to take effect, that might not work.

> 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/ 
> 
> 
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
-- 
Ken Gaillot <kgaillot at redhat.com>