> On 21 Aug 2015, at 2:21 am, Jehan-Guillaume de Rorthais <j...@dalibo.com> > wrote: > > On Thu, 20 Aug 2015 15:05:24 +1000 > Andrew Beekhof <and...@beekhof.net> wrote: > >> >>> 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. > > BTW, how other official RA are dealing with this?
They’re not, but in this case it seems there could be good reasons to separate them > 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. _______________________________________________ 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