Stupid question, but if quorum is being calculated in quorumd, shouldn't clients get it from there directly? What's the advantage to corosync being involved (other than as a client itself)? > > On Wed, Aug 17, 2011 at 6:26 PM, Fabio M. Di Nitto <fdinitto@xxxxxxxxxx> wrote: >> Hi all, >> >> for a long time cman has been the quorum provider within RHCS. cman is >> going to be obsoleted in the long term and a replacement needs to be >> implemented. >> >> In this proposal I left out API names.. they are not important at this >> stage and can be defined later on (also because some interfaces like >> confdb/objdb might change in 2.0). >> >> I am also assuming that we want the option to plug different quorum >> providers into the system (network based, disk based, etc) and different >> algorithms to calculate quorum (YKD, etc). >> >> Attached to this email there is a small pdf with the data flow diagram >> as one picture can explain better than 1000 words (at least given my >> level of itaglish ;)) >> >> Keep always in mind that: >> >> 1) At any given time, only one "cluster view provider" feeds information >> to quorumd. The provider must be the same across all nodes. >> >> 2) At any given time, only one "quorum calculation algorithm" can be >> used and it must be the same across all nodes. >> >> 3) disk based provider can either be a separate daemon or run within >> quorumd. Due to the nature of the provider, the implementation needs >> either threads or libaio (that´s not very portable) and therefor it >> cannot run within corosync directly for blocking reasons. >> >> 4) a quorum state change, has to trigger a cpg_1 notification (assuming >> that we will use cpg as notification method, but that would save the >> issue of synchronizing cpg notifications with quorum ones). >> >> 5) dispatch of notification between cpg_0 and cpg_1 has to be >> synchronized to allow quorumd to act on network based cluster view >> provider. In theory the only user for cpg_0 is quorumd. >> _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
