On 16/06/16 13:54, Vladislav Bogdanov wrote: > 16.06.2016 15:28, Christine Caulfield wrote: >> 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. > > But it looks at it on a config reload, allowing to change > wait_for_all_status from 0 to 1, but not vice versa. And reload does not > look at "ro" - I though it does. That's fine. > IIUC, even after this change I still have everything working as expected > (I actually did not look at that part of code before): > > Setting wait_for_all to 0 and two_node to 1 in config (both were not set > at all prior to that) and then reload leaves wait_for_all_status=0 and > NODE_FLAGS_WFASTATUS bit unset in flags. But setting wait_for_all to 1 > after that (followed by another reload) sets wait_for_all_status=1 and > NODE_FLAGS_WFASTATUS bit.
Interesting. I'm not sure that's intended but it sounds safe :) I'll look into it though - if only for my own curiousity. > > Great, thank you! _______________________________________________ Users mailing list: Users@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