[ClusterLabs Developers] Resource Agent language discussion
andrew at beekhof.net
Thu Aug 20 01:05:24 EDT 2015
> 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>
>>> 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?”.
>> 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.
> * 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, ...
More information about the Developers