Configuring unicast mode is confusing
Opened this issue · 1 comments
Affected Puppet, Ruby, OS and module versions/distributions
- Puppet: 5.5.22
- Ruby: 2.4.10p364
- Distribution: CentOS 7.9.2008
- Module version: 7.0.0
How to reproduce (e.g Puppet code you use)
class pg {
class { 'corosync':
bind_address => $facts['networking']['interfaces']['eth0']['ip'],
cluster_name => 'pg12',
enable_secauth => false,
set_votequorum => true,
quorum_members => [ 'pgsql01', 'pgsql02' ],
unicast_addresses => [ '192.168.100.200', '192.168.100.212']
}
corosync::service { 'pacemaker':
version => '0',
}
cs_property { 'stonith-enabled':
value => 'false',
}
cs_property { 'no-quorum-policy':
value => 'ignore',
}
}What are you seeing
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
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:
Is there a reason why corosync need this declaration?