You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to have transport set to udpu it it necessary to populate unicast_addresses but these values are not actually populated into corosync.conf when set_votequorom => true which is the default setting on Red Hat (and derivatives).
What behaviour did you expect instead
It seems confusing to set a value which is not used directly but instead used to infer another value. I could put complete rubbish in unicast_addresses and still get the same output. Should there not be an explicit transport param or at least some way to explicit state you want to use udpu transport?
Output log
Any additional information you'd like to impart
The text was updated successfully, but these errors were encountered:
agriffit79
changed the title
Configuring unicast mode is configusing
Configuring unicast mode is confusing
Dec 14, 2020
I agree with you, this system is strange. I also have a udpu system with several rings (corosync 2.4.3 and pacemake 1.1.18). However, I need to declare a bindnetaddr or pacemaker have a lot of trouble to run.
The disabling of member have been introduced in #430 to resolve #421. @btravouillon has stated that member are not needed (#422 (comment)) which is confirmed by corosync/corosync@de70c00.
However, I have found useful to put the bindnetaddress outside of the set_votequorum condition, so to invert those lines:
Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce (e.g Puppet code you use)
What are you seeing
In order to have transport set to
udpu
it it necessary to populateunicast_addresses
but these values are not actually populated intocorosync.conf
whenset_votequorom => true
which is the default setting on Red Hat (and derivatives).What behaviour did you expect instead
It seems confusing to set a value which is not used directly but instead used to infer another value. I could put complete rubbish in
unicast_addresses
and still get the same output. Should there not be an explicittransport
param or at least some way to explicit state you want to use udpu transport?Output log
Any additional information you'd like to impart
The text was updated successfully, but these errors were encountered: