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). Fabio _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
