[corosync] [RFC] changing libquorum API

Andrew Beekhof andrew at beekhof.net
Wed Dec 14 00:14:30 GMT 2011

On Wed, Dec 14, 2011 at 9:37 AM, Steven Dake <sdake at redhat.com> 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:
>> 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).


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)

More information about the discuss mailing list