So nodelist is approximately totem++?
wfm. with Fabio's exception about not being strictly mandatory for
quorum and Dave's for defaulting votes=1.
"ringN_interface" is a little clumsy, but I can understand trying to
avoid another {}-block.
Is multiple "instance:" values feasible (with the ringN_ being implied)?
On Sat, Jan 14, 2012 at 4:10 AM, Steven Dake <sdake@xxxxxxxxxx> wrote:
> On 01/10/2012 03:08 AM, Fabio M. Di Nitto wrote:
>> Hi all,
>>
>> in some recent discussions, it come up the issue on how to configure
>> quorum module. As I don´t really have a complete solution yet, I need to
>> seek advice in the community :)
>>
>> Problem:
>>
>> it would be very nice if corosync.conf could be simply scp´ed/copied
>> between nodes and everything works as expected on all nodes.
>> Issue being that some quorum bits are, at this point in time, node
>> specific. It means that to alter some values, it is necessary to edit
>> corosync.conf on the specific node.
>> On top of that, it would be nice if expected_votes could be
>> automatically calculated based on votes: values.
>>
>> The current quorum configuration (based on topic-quorum patches):
>>
>> quorum {
>> provider: corosync_votequorum
>> expected_votes: 8
>> votes: 1
>> two_node: 0
>> wait_for_all: 0
>> last_man_standing: 0
>> auto_tie_breaker: 0
>> }
>>
>> totem {
>> nodeid: xxx
>> }
>>
>> The 2 values that cannot be copied around are quorum.votes and totem.nodeid.
>>
>> In current votequorum/totem incarnation, votes/expected_votes/nodeid are
>> all broadcasted to all nodes. so each node that joins the cluster
>> becomes aware of the other peers values.
>>
>> As a consequence of the current config format, auto_tie_breaker feature,
>> requires wait_for_all to work (in order to have the complete list of
>> nodeids, see auto_tie_breaker implementation in topic-quorum branch for
>> details).
>>
>> Honza and I quickly explored options to add those values into the node
>> list of udpu, but that´s limiting because it doesn´t work well in
>> multicast and/or broadcast and it has integration issues with RRP.
>>
>> Also adding lists to quorum {} involves a certain level of duplicated
>> information.
>>
>> For example:
>>
>> quorum {
>> nodeid_list: x y z...
>> node.x.votes: ..
>> node.y.votes: ..
>> }
>>
>> that IMHO is all but nice to look at.
>>
>> So the question of changing the config format also raise the following
>> questions:
>>
>> 1) do we really need to support an auto_tie_breaker feature without
>> wait_for_all? if NO, then we don´t need the list of nodeids upfront.
>>
>> 2) do we really care about votes other than 1? If NO, then votes: can
>> simply be dropped from corosync.conf defaults, and in case an override
>> is necessary, it can be done specific to the node. This solution poses
>> the problem that expected_votes need to be set in corosync.conf (one
>> liner in the config file vs different liners) but it might be slightly
>> more tricky to calculate if votes are not balanced.
>>
>> Please let me know your opinions and we need to come down to an
>> agreement rather soon, since this might be a blocker for corosync 2.0
>> release.
>>
>
> My suggestion is detailed and has detailed requirements, so please read
> through and see if this meets the interested parties needs.
>
> nodelist {
> node X {
> ring0_interface: 192.168.1.1
> ring1_interface: 192.168.2.1
> nodeid: 1
> quorum_votes: 1
> }
> node Y {
> ring0_interface: 192.168.1.2
> ring1_interface: 192.168.2.2
> nodeid: 2
> quorum_votes: 2
> }
> }
>
> + nodelist is optional (mandatory when using quorum or UDPU
> + X is just a name which doesn't use the resolver but could be the DNS
> name of the machine
> + nodeid is the node identifier of the containing node.
> + nodeid is mandatory for IPV6 networks, optional for IPV4 networks
> + nodeid will be autogenerated from the ip address if not specified
> + quorum_votes is mandatory if a quorum stanza is defined, otherwise ignored
>
> quorum {
> provider: corosync_votequorum
> two_node: 0
> wait_for_all: 0
> last_man_standing: 0
> auto_tie_breaker: 0
> }
>
> + expected_votes is removed and instead auto-calculated based upon
> quorum_votes in the node list
> + votes is moved to the individual node list
>
> totem {
> }
>
>
> node id being set with node list defined prints a warning that node id
> in totem stanza is deprecated and ignored.
> if transport: udpu is specified without the node list stanza, the
> configuration is rejected printing a warning that the node list must be
> specified to operate in udpu mode
> if the udpu member stanzas are specified, the configuration is printing
> a warning that the udpu member stanza has changed
>
> logging {
> }
> remains unchanged
>
> remove service section entirely
> if service section is parsed, print warning that service section is
> deprecated and ignored
>
> What we get:
> + full ability to copy 1 configuration file to all nodes assuming they
> are in the same subnet with the same interface netmasks
> + node list specified in one place
> + If expected votes is needed, it can be calculated from the node list
> rather then hard specified
> + old configuration files will work as they always have (with exception
> of transport: udpu), but not well with quorum. This isn't a problem
> because likely people are not using quorum already.
> + When totem determines its IP address via binding, it can then lookup
> the node id in the node list (if its defined, or autogenerate)
>
> What we lose:
> Configurations with the UDPU stanza will need to be modified before
> upgrading the software
>
> Assuming folks agree on the general principles, We can slip the current
> schedule 1 week up to RC4. RC5 would be removed from the schedule and
> the end release date (3/13) remains the same assuming no problems during
> the RC process.
>
> Regards
> -steve
>
>
>> Thanks
>> Fabio
>> _______________________________________________
>> discuss mailing list
>> discuss@xxxxxxxxxxxx
>> http://lists.corosync.org/mailman/listinfo/discuss
>
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
