On 01/11/2012 09:26 AM, Digimer wrote:
> On 01/11/2012 11:03 AM, David Teigland wrote:
>>> quorum {
>>> nodeid_list: x y z...
>>> node.x.votes: ..
>>> node.y.votes: ..
>>> }
>>
>> I'd suggest a general nodes section that allows all nodes to be specified
>> along with their properties.
>>
>> When corosync starts up, it would pick out its own entry in that nodes
>> section, and if it doesn't find one, it would fail to start.
>>
>> A node entry needs ipaddr, nodeid, votes. A hostname might be nice also.
>> Something like
>>
>> nodes {
>> node {
>> ipaddr: 1.1.1.1
>> nodeid: 1
>> votes: 1
>> }
>>
>> node {
>> ipaddr: 2.2.2.2
>> nodeid: 2
>> votes: 1
>> }
>> }
>>
>> With no nodeid specified, nodeid would default to ipaddr unless it's ipv6.
>> With no votes specified, votes would default to 1.
>>
>> By default the quorum module would calculate expected votes by adding the
>> individual node votes (a different explicit expected votes value could be
>> specified in the quorum config block to override this.)
>>
>> There shouldn't be any node-specific config values outside the node
>> sections so that the config file can be the same on all nodes.
>
> +1
>
> If a host name is to be specified, and if the possibility exists, I'd
> prefer to have the directive's name be the host name;
>
> nodes {
> foo1 {
> ipaddr: ...
> nodeid: 1
> votes: 1
> }
> foo2 {
> ,,,
> }
> }
>
Regarding hostname, corosync won't be doing gethostbyname() calls as
they block. This is why ip addresses are used.
Regards
-steve
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
