[ClusterLabs] Corosync 2.3.6 is available at corosync.org!

[Christine Caulfield]

On 16/06/16 13:22, Vladislav Bogdanov wrote:
> Hi,
> 
> 16.06.2016 14:09, Jan Friesse wrote:
>> I am pleased to announce the latest maintenance release of Corosync
>> 2.3.6 available immediately from our website at
>> http://build.clusterlabs.org/corosync/releases/.
> [...]
>> Christine Caulfield (9):
> [...]
>>        Add some more RO keys
> 
> Is there a strong reason to make quorum.wait_for_all read-only?
> 

It's almost a no-op for documentation purposes. corosync has never
looked at that value after startup anyway. This just makes sure that an
error will be returned if an attempt is made to change it.

Chrissie

> In one of products I use the following (fully-automated) actions to
> migrate from one-node to two-node setup:
> 
> == mark second node "being joined"
> * set quorum.wait_for_all to 0 to make cluster function if node is
> reboot/power is lost
> * set quorum.two_node to 1
> * Add second node to corosync.conf
> * reload corosync on a first node
> * configure fencing in pacemaker (for both nodes)
> * copy corosync.{key,conf} to a second node
> * enable/start corosync on the second node
> * set quorum.wait_for_all to 1
> * copy corosync.conf again to a second node
> * reload corosync on both nodes
> == Only at this point mark second node "joined"
> * enable/start pacemaker on a second node
> 
> I realize that all is a little bit paranoid, but actually it is handy
> when you want to predict any problem you are not aware about yet.
> 
> Best regards,
> Vladislav
> 
> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org