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