[ClusterLabs] RRP is broken ... in what ways?
jpokorny at redhat.com
Wed Apr 17 12:29:18 EDT 2019
On 10/04/19 15:31 +0200, Jan Pokorný wrote:
> On 08/04/19 19:08 +0200, Jan Friesse wrote:
>> Anyway. RRP is broken,
> Since this is repeatedly rehashed on this list without summarizing
> *what* is that much broken while serving (rather well, I think)
> last 8+ years, perhaps it would deserve some wider dissemination
> incl. *why* is that.
> Closest thing to come to mind is this, though I don't think
> it's a well known reference:
> In addition, there are minor notes here and there to be found, e.g.,
> on the topic of the networks being presumably of comparable
> characteristics with RRP [2,3]:
>> It should probably be documented somewhere but may not be, with
>> redundant ring, both rings must be of approximately the same
>> The protocol is designed to limit to the speed of the slowest ring
>> - perhaps this is not working as intended.
>  https://lists.clusterlabs.org/pipermail/users/2019-March/025491.html
>  https://discuss.corosync.narkive.com/jUynoGxv/totem-implementation-is-unreliable-ring-faulty-and-retransmit-list#post2
>  https://lists.clusterlabs.org/pipermail/pacemaker/2011-August/058536.html
> Can you perhaps give a definite answer here to arising "what" and "why",
> also perhaps to provide a credible incentive to upgrade out of something
> just sketchily referred to as "broken", please?
No conclusive summary on the subject (so far taken rather for a fact
here, where I guess corosync experts are a vast minority) to afford us
the liberty of educated choice regarding the upgrade beyond allegedly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Users