[ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion

[Andrew Beekhof]

> 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.

> but this is
> not a drama from my PoV, the discussion is not about that. As I wrote earlier:
> «
> 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
> »
> 
> 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.

>  * is there a chance a perl version of such library would be accepted upstream?

Depends if you’re volunteering to maintain it too :)

> 
> Note that in the Pacemaker galaxy, fencing agent are written in python, perl,
> C, ...
> 
> Regards,