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