[ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion

[Jehan-Guillaume de Rorthais]

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