Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[booth] pcs booth status does not reflect where is the cluster-local booth representative running (if so) #230

Open
jnpkrn opened this issue Dec 11, 2019 · 1 comment

Comments

@jnpkrn
Copy link
Contributor

jnpkrn commented Dec 11, 2019

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:

  1. realize whether the home node is part of the cluster with multisite
    clustering configured

  2. if so, it shall deduce where the local cluster representative is
    currently running within cluster, and route the request over there[*]

  3. 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 list and booth status
  • B. utilize "distributed/non-local connectivity" of booth,
    allowing for booth status command to return non-success
    and replacing the booth list -c booth command with
    booth list -s <booth virtual IP>

    • this only deals with booth list side 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)
@tomjelinek
Copy link
Member

Due to time constraints and other priorities, we haven't been able to implement these planned higher level booth commands which would be aware of the whole booth formation and which would be able to operate at a cluster level and booth formation level. For the users to be able to set booth at least somehow, only the node-level commands have been implemented. Those, even if not as comfortable as one may desire, provide a complete set of operations needed for configuring and managing booth.

The plans for the more comfortable booth management are still there. Unfortunately given current developer resources and backlog, it is a "blue-sky" project for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants