[corosync] [RFC] changing libquorum API

Fabio M. Di Nitto fdinitto at redhat.com
Wed Dec 14 04:58:13 GMT 2011

On 12/14/2011 01:14 AM, Andrew Beekhof wrote:
> 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).
> 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.

The public header will contain the defines for QUORUM_FREE/QUORUM_SET
and yes the autotool bit is easy to do (I'll have to look it up tho
because I don't remember it OTOH).


More information about the discuss mailing list