On Wed, Dec 14, 2011 at 3:58 PM, Fabio M. Di Nitto <fdinitto@xxxxxxxxxx> wrote: > On 12/14/2011 01:14 AM, Andrew Beekhof wrote: >> On Wed, Dec 14, 2011 at 9:37 AM, Steven Dake <sdake@xxxxxxxxxx> wrote: >>> On 12/13/2011 11:16 AM, Fabio M. Di Nitto wrote: >>>> On 12/13/2011 5:55 PM, Steven Dake wrote: >>>>> On 12/13/2011 07:17 AM, Fabio M. Di Nitto wrote: >>>>>> Quoting: >>>>>> >>>>>> https://github.com/corosync/corosync/commit/ebbba5b05b05a0943dce50be16282657a31c2e05 >>>>>> >>>>>> corosync internal theory of operation is that without a quorum provider >>>>>> the cluster is always quorate. This is fine for membership free clusters >>>>>> but it does pose a problem for applications that need membership and >>>>>> "real" quorum. >>>>>> >>>>>> this change add quorum_type to quorum_initialize call to return QUORUM_FREE >>>>>> or QUORUM_SET. Applications can then make their own decisions to error out >>>>>> or continue operating. >>>>>> >>>>>> The only other way to know if a quorum provider is enabled/configured is >>>>>> to poke at confdb/objdb, but adds an unnecessary burden to applications >>>>>> that really don't need to use an entire library for a boolean value. >>>>>> >>>>>> I am clearly at RFC stage since variable/const names are up for >>>>>> discussion/improvement. >>>>>> >>>>>> The other option to approach this issue is to use a 3 state is_quorate, >>>>>> but that can break applications (and corosync internal) in a more subtle >>>>>> way. By changing the API in such a simple way, old applications will >>>>>> fail to build (in one function only) and will get the info they need >>>>>> right away. >>>>>> >>>>> >>>>> Fabio, >>>>> >>>>> Type concept looks ok, but don't want to change quorum_initialize unless >>>>> absolutely necessary. >>>>> >>>>> Can you make a case for changing quorum_initialize directly rather then >>>>> adding a : >>>>> >>>>> "quorum_type_get() which could be called directly after? I realize it >>>>> is two calls, but then ABI remains backward compat. >>>>> >>>> >>>> Because not all downstreams will add that call because their piece of >>>> software will keep building just fine and they don´t know what they are >>>> getting basically. >>>> >>>> The problem, as I see it, is that without a quorum provide (that being >>>> ykd or majority or cman) corosync is always quorate and quorum >>>> notifications are not dispatched as there is really never a change >>>> there. This also causes application to hang in some cases. >>>> >>>> If an application needs quorum provider and membership, they need to >>>> know that. Either we change init call or each application needs to do >>>> some fancy calls into the objdb/cmap (that IMHO is overloaded). >>>> >>>>> Another option would be to add a qourum_type notification callback >>>>> (since this wouldn't break the ABI backwards compatibility) but this >>>>> would probably have to be coupled with qourum_type_get to be useful for >>>>> users. >>>> >>>> I am not sure I see the point in adding it to a call back because we >>>> can´t change quorum provider dynamically. It´s set in stone at startup >>>> and might as well know right away if it´s an ok type or not. >>>> >>>> I am up to discuss other options.. but I think this is the safest one >>>> that will propagate the concept of quorum_type immediately. >>>> >>>> I also investigated the possibility of using a numerated is_quorate around: >>>> >>>> QUORUM_ALWAYS_QUORATE -1 >>>> QUORUM_NOT_QUORATE 0 >>>> QUORUM_IS_QUORATE 1 >>>> >>>> but that´s even worst because it does require investigation of a lot of >>>> code to make sure we don´t break anything in a subtle way. >>>> >>>> Fabio >>>> >>> >>> Ok argument makes sense. Could you do me a favor though, and place it >>> as the 3rd parameter (the type). >> >> Ack. >> >> Anyone know how to test which function signature to use with autotools? >> At a minimum we could infer it based on the availability of a related >> #define or enum value, but they'd need to be in a public (installed) >> header. > > The public header will contain the defines for QUORUM_FREE/QUORUM_SET > and yes the autotool bit is easy to do (I'll have to look it up tho > because I don't remember it OTOH). > As long as the define is there I can handle the rest :-) _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
