[ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion

[Andrew Beekhof]

> On 21 Aug 2015, at 2:21 am, Jehan-Guillaume de Rorthais <jgdr at dalibo.com> wrote:
> 
> On Thu, 20 Aug 2015 15:05:24 +1000
> Andrew Beekhof <andrew at beekhof.net> wrote:
> 
>> 
>>> On 19 Aug 2015, at 6:59 pm, Jehan-Guillaume de Rorthais <jgdr at dalibo.com>
>>> wrote:
>>> 
>>> On Mon, 17 Aug 2015 09:42:35 +1000
>>> Andrew Beekhof <andrew at beekhof.net> wrote:
>>> 
>>>>> On 11 Aug 2015, at 5:34 pm, Jehan-Guillaume de Rorthais <jgdr at dalibo.com>
>>>>> wrote:
>>>>> 
>>>>> On Tue, 11 Aug 2015 11:30:03 +1000
>>>>> Andrew Beekhof <andrew at beekhof.net> wrote:
>>> [...]
>>>>>> You can and should use whatever language you like for your own private
>>>>>> RAs. But if you want it accepted and maintained by the resource-agents
>>>>>> project, you would be advised to use the language they have standardised
>>>>>> on.
>>>>> 
>>>>> Well, let's imagine our RA was written in bash (in fact, we have a bash
>>>>> version pretty close to the current perl version we abandoned). I wonder
>>>>> if it would be accepted in the resource-agents project anyway as another
>>>>> one already exists there. I can easily list the reasons we rewrote a new
>>>>> one, but this is not the subject here.
>>>>> 
>>>>> The discussion here is more about the language, if I should extract a
>>>>> ocf-perl-module from my RA and if there is any chance the resource-agents
>>>>> project would accept it.
>>>> 
>>>> Well, it depends on the reasons you didn’t list :-)
>>> 
>>> Ok, let's answer the questions then :)
>>> 
>>>> The first questions any maintainer is going to ask are:
>>>> - why did you write a new one?
>>> 
>>> About the existing pgsql RA:
>>> * it supports stateless AND multistate pgsql resource. It makes the code
>>>   bigger, more complexe, hard to follow and understand
>>> * some params are for multistate usage only, some other for stateless only,
>>>   some for both, making the configuration harder to understand
>>> * some params are required for multistate where a recent PostgreSQL can
>>> live without them (restore_command)
>>> * it achieves operations a RA should not take care of (switching from
>>>   synchronous to asynchronous replication on the master if slaves are gone,
>>>   killing all existing xact)
>>> * ...and this makes the code even bigger and complexe again
>>> * it supports too many options and has some conventions the DBA should care
>>>   themselves. This make it way too complex and touchy to setup and maintain
>>> * it does not support demote, making the code lying about the real
>>>   state of the resource to Pacemaker. This was because demote/switchover
>>> was unsafe for postgresql < 9.3.
>>> 
>>> What we tried to achieve with a new pgsql RA:
>>> * multistate only (we already have a stateless RA, in bash)
>>> * should have a simple code: easier to understand, to maintain, achieve one
>>>   goal at a time
>>> * be simple to setup
>>> * should not substitute itself to the DBA
>>> * support safe ("cold") demote/switchover
>>> 
>>>> - can we merge this with the old one?
>>> 
>>> Well, it would make the code even bigger, maybe conflicting and harder to
>>> understand. I already can hear questions about such a frankenstein RA
>>> ("why am I able to setup two different multistate architecture?" "why this
>>> one does not supports this parameter?" "should I create my recovery.conf or
>>> not?")
>>> 
>>> Some of our ideas could be merged to the old one though, we could discuss
>>> and help maintainers if they are interested and have time. But we only have
>>> a limited R&D time and have no time to lead such a development.
>>> 
>>>> - can the new one replace the old one? (ie. full superset)
>>> 
>>> No. It does not support stateless resource, does not mess with replication
>>> synchronism, does not kill queries if all the slaves are gone, does not
>>> "lock" an instance when it failed, only promote the resource using "pg_ctl
>>> promote" (with no restart), ...
>>> 
>>>> Because if both are included, then they will forevermore be answering the
>>>> question “which one should I use?”.
>>> 
>>> True.
>>> 
>>>> Basically, if you want it accepted upstream, then yes, you probably want to
>>>> ditch the perl bit. But not having seen the agent or knowing why it exists,
>>>> its hard to say.
>>> 
>>> Well, it seems our RA will not make it to the upstream repository,
>> 
>> You made a fairly reasonable argument for separate stateless and stateful
>> variants.
> 
> BTW, how other official RA are dealing with this?

They’re not, but in this case it seems there could be good reasons to separate them

> A quick look at RA names
> seems to reveal no service have dedicated stateless and stateful RA scripts.
> 
> [...]
>>> What I was discussing here was:
>>> 
>>> * if not using bash, is there any trap we should avoid that are already
>>>   addressed in the ocf-shellfuncs library?
>> 
>> No, you just might have to re-implement some things.
>> Particularly logging.
> 
> Ok, that was my conclusion so far. I'll have a look at the logging funcs then.
> 
>>> * is there a chance a perl version of such library would be accepted
>>> upstream?
>> 
>> Depends if you’re volunteering to maintain it too :)
> 
> I do. I'll have to do it on my own for my RA anyway.