> On 19 Aug 2015, at 6:59 pm, Jehan-Guillaume de Rorthais <j...@dalibo.com> > wrote: > > On Mon, 17 Aug 2015 09:42:35 +1000 > Andrew Beekhof <and...@beekhof.net> wrote: > >>> On 11 Aug 2015, at 5:34 pm, Jehan-Guillaume de Rorthais <j...@dalibo.com> >>> wrote: >>> >>> On Tue, 11 Aug 2015 11:30:03 +1000 >>> Andrew Beekhof <and...@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, _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org