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