On 16/06/16 14:09, Vladislav Bogdanov wrote: > 16.06.2016 16:04, Christine Caulfield wrote: >> 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. > > Please do not fix^H^H^Hbreak that!
I will be careful :) Chrissie > But some inline documentation about the current behavior is worth adding ;) > > >> >>> >>> Great, thank you! >> >> >> _______________________________________________ >> Users mailing list: [email protected] >> 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 >> > > > _______________________________________________ > Users mailing list: [email protected] > 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 _______________________________________________ Users mailing list: [email protected] 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
