[ClusterLabs Developers] Resource Agent language discussion

[Jehan-Guillaume de Rorthais]

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, 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?
  * is there a chance a perl version of such library would be accepted upstream?

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

Regards,