On 8/17/2011 11:21 AM, Christine Caulfield wrote: > On 17/08/11 09:26, Fabio M. Di Nitto 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. >> >> 6) quorumd is optional. corosync should work with or without. cpg_1 >> clients will get different quorum info (QUORATED, NOT_QUORATED, >> QUORUM_INFO_NOT_AVAILABLE, etc) based on the status. > > A minor point but the language is simple QUORATE and not QUORATED
eheh noted :) > > >> 7) quorumd will require some configuration or information to be able to >> act correctly. For example "how many nodes are supposed to be in the >> cluster?" etc. This is an implementation detail but it is something to >> take into account. Most of those information are tight to the quorum >> calculation algorithm and we will need to evaluate on a case by case how >> to handle it correctly. > > How a quorum provider calculates quorum is entirely up to it and cannot > be provided by lower layers really. It can ask for services (such as > number of nodes, as you mentioned) but don't try to build anything more > specific into the quorum interface as it'll just look silly and be > ignored by most providers. Let them provide their own APIs for > requesting data. What I did with quorum/votequorum might not be ideal > but it shows the level of separation that's needed I think. Right, that´s why I didn´t go anywhere the specifics of that APIs, but just as something to keep in mind when we will get there. The initial discussion was based around quorum/votequorum so that´s going to be a starting point and not the end of it. It might change but that´s probably expected. Fabio _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
