-
Notifications
You must be signed in to change notification settings - Fork 119
Description
In case you happen to run said command in case you didn't pick the
right, "currently representative" node, you get to see an unexpected
outcome:
# pcs booth status
> Error: unable to get status of booth daemon: Dec 10 20:40:10 virt-154 booth: [13424]: error: Cannot find myself in the configuration.
Well, of course, you cannot, since pcs invoked you at the wrong node
(lazily, just the local one right away).
What should pcs have done instead:
-
realize whether the home node is part of the cluster with multisite
clustering configured -
if so, it shall deduce where the local cluster representative is
currently running within cluster, and route the request over there[*] -
if not, currentl behaviour is likely fine, expect to report
from local arbitrator POV
[*] regarding "routing the request (soliciting info), there are
2 possiblities:
-
A. utilize presumed pcs intra-node communication infrastructure,
route the request to the target node using pcs-native means,
than route the response back the same way- this is preferred to satisfy reporting from booth
booth listandbooth status
- this is preferred to satisfy reporting from booth
-
B. utilize "distributed/non-local connectivity" of booth,
allowing forbooth statuscommand to return non-success
and replacing thebooth list -c boothcommand with
booth list -s <booth virtual IP>- this only deals with
booth listside of the report,
hence A. is strongly recommended (when applied within
cluster, you want to get the same information back
regardless if where the cluster-local booth representative
is running)
- this only deals with