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

[Vladislav Bogdanov]

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!
But some inline documentation about the current behavior is worth adding ;)


>
>>
>> Great, thank you!
>
>
> _______________________________________________
> 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
>