URL:
Reporter RHNID:
Section: -
Language: en-US (English)
Workaround:

Description: Description of the output of corosync-quorumtool as discussed on page 40-41 talks about 'expected votes' and 'highest expected'. During testing I was unable to create a scenario whereby these would be different. Please see the included transcript of an email conversation that I had with a votequorum developer Christine Caulfield.

In summary therefore I think the description of 'highest expected' should be changed to something like "this is expected to always be the same as 'expected votes' except in a misconfigured cluster" because at the moment students question why it is there at all

=====================================
The question concerns the difference between the two terms 'expected votes' and 'highest expected'. According to the guide that we provide the students 'expected votes' is "the number of votes that are present if all configured cluster members are active in the cluster" whereas 'highest expected' is "the largest count of expected votes seen in the cluster".
>
> So far I have never been able to make the two values different from each other. Under what circumstances would I see 'expected votes' have a different value to 'highest expected'?
>
> I have tried creating a cluster and then removing a node using pcs cluster node remove but that still results in the two fields having the same value. Unfortunately I don't have a cluster classroom to play with at the moment but I did not notice that there was an option in one of the configuration files (related to downscaling possibly?) whereby if I set that then when I removed a node from the cluster as above it still showed the expected votes as the maximum that it had been previously. However the two fields 'expected votes' and 'highest expected' were still the same.
>
> As students see these definitions as shown above if the behaviour of the fields is not clear then I would like to suggest to the curriculum team that they adjust the manual so students don't start asking questions about these fields.
>
> If you are able to throw any light on this it would be much appreciated.
>

Hi David.

That's a really good question and the answer is actually quite simple.
Those two values should always be the same

If they are different then there is a bad misconfiguration going on -
perhaps one node has a different expected_votes value than another (this
should not happen, but if people manually edit files it could).
Votequorum tries very hard to keep expected_votes sane, after all it's
what prevents split-brain so is fundamental to the cluster's validity,
but there is always a chance of a slip between chair and keyboard

To be clear about this, what the 'highest_expected' value is not is the
largest value that the cluster has ever known. That's actually the
'ev_tracking_barrier' and is only visible through cmap, and is only used
when starting a new node (in an existing cluster) when allow_downscale
is enabled.

highest_expected is simply the largest value of expected_votes that
corosync could see at the last transition.