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