-
Notifications
You must be signed in to change notification settings - Fork 116
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 sync
does not synchronize configuration to other clusters
#226
Comments
To sync booth configs across cluster, you do The improvement you are proposing is reasonable and we will consider it once pcs has awareness of multiple sites. |
Why do you close this issue then? Also, that composition is borderline impractical & inconvenient, Certainly, there is a lot to left to be desired, hence this issue, |
Regarding |
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. |
This especially makes that command useless when degenerate
single node clusters are considered, but nonetheless, the point of
the management tool is to make the typical workflows easy, and
"sync across the clusters" is one such typical use case for multisite
nonetheless -- that's exactly what you want to do with
booth sync
,don't you?!
Relevant issue here: #224
Note that the motivation example there already works with the
mechanism of "virtual (booth) IP to cluster mapping", which is
exactly what fits into this picture. Good news is that
pcsd
listeningon
[::]:*
by default and, as tested, will gladly serve the requestscoming via a virtual IP introduced even once
pcsd
got started.The text was updated successfully, but these errors were encountered: