>>> Ken Gaillot <kgail...@redhat.com> schrieb am 28.04.2021 um 19:00 in Nachricht <e3ed5c7619254da8ed509cb5cdec835d3e7bb686.ca...@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 <kgail...@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/
