aos-sno-pair enhancement #831
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
mshitrit
force-pushed
the
aos-sno-pair
branch
3 times, most recently
from
eb51030
to
fd310de
Compare
|
/retest |
1 similar comment
|
/retest |
|
If this is a priority for the current quarter or release, you can use |
mshitrit
force-pushed
the
aos-sno-pair
branch
2 times, most recently
from
83999ab
to
7afcbc7
Compare
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
| _The "two node cluster" is a use case that requires special consideration. With a standard two node cluster, each node with a single vote, there are 2 votes in the cluster. Using the simple majority calculation (50% of the votes + 1) to calculate quorum, the quorum would be 2. This means that the both nodes would always have to be alive for the cluster to be quorate and operate._ | ||
| <br>Source: man votequorum | ||
|
|
||
| For environments in which customers will allow it, Corosync also ships a lightweight quorum arbitrator that can be run locally or in the cloud on any non-cluster node. In such cases, no special quorum handling is required and careful placement of the arbitrator also ensures that the surviving peer is reachable by its intended clients. |
There was a problem hiding this comment.
Corosync is written in C what team supports this currently?
There was a problem hiding this comment.
We've recently had some conversations about the difference in support lifecycles for RHEL and OCP. It would be good to call that out as a risk in this doc.
There was a problem hiding this comment.
Aren't RHEL based products generally supported for much longer than OCP? What specific concerns have been raised?
The RHEL-HA team has a long history of being extremely responsive when bugs are found and proactive when it comes to backports.
There was a problem hiding this comment.
IIRC, the RHEL lifetime was less than what we've been asked to support for OCP. Either way, the timelines don't always align, which makes extended support challenging sometimes.
Signed-off-by: Michael Shitrit <mshitrit@redhat.com>
| _The "two node cluster" is a use case that requires special consideration. With a standard two node cluster, each node with a single vote, there are 2 votes in the cluster. Using the simple majority calculation (50% of the votes + 1) to calculate quorum, the quorum would be 2. This means that the both nodes would always have to be alive for the cluster to be quorate and operate._ | ||
| <br>Source: man votequorum | ||
|
|
||
| For environments in which customers will allow it, Corosync also ships a lightweight quorum arbitrator that can be run locally or in the cloud on any non-cluster node. In such cases, no special quorum handling is required and careful placement of the arbitrator also ensures that the surviving peer is reachable by its intended clients. |
There was a problem hiding this comment.
We've recently had some conversations about the difference in support lifecycles for RHEL and OCP. It would be good to call that out as a risk in this doc.
Co-authored-by: Andrew Beekhof <andrew@beekhof.net>
Signed-off-by: Michael Shitrit <mshitrit@redhat.com>
Signed-off-by: Michael Shitrit <mshitrit@redhat.com>
…ter" * using relative link for resource file Signed-off-by: Michael Shitrit <mshitrit@redhat.com>
Signed-off-by: Michael Shitrit <mshitrit@redhat.com>
Signed-off-by: Michael Shitrit <mshitrit@redhat.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Michael Shitrit <mshitrit@redhat.com>
Co-authored-by: Eran Cohen <eranco@redhat.com>
Signed-off-by: Michael Shitrit <mshitrit@redhat.com>
# Conflicts: # enhancements/single-node/aos-sno-pair.md
|
Inactive enhancement proposals go stale after 28d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
Stale enhancement proposals rot after 7d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle rotten |
openshift-ci
bot
added
lifecycle/rotten
|
/remove-lifecycle stale |
|
/remove-lifecycle rotten |
openshift-ci
bot
removed
the
lifecycle/rotten
|
Closing this. |
|
/close |
|
@beekhof: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
The conversation arrived at the conclusion that while the design is not objectionable, the result should not be part of ocp. |
Signed-off-by: Michael Shitrit mshitrit@redhat.com