On Thu, 20 Aug 2015 15:05:24 +1000 Andrew Beekhof <[email protected]> wrote:
> > > On 19 Aug 2015, at 6:59 pm, Jehan-Guillaume de Rorthais <[email protected]> > > wrote: > > > > On Mon, 17 Aug 2015 09:42:35 +1000 > > Andrew Beekhof <[email protected]> wrote: > > > >>> On 11 Aug 2015, at 5:34 pm, Jehan-Guillaume de Rorthais <[email protected]> > >>> wrote: > >>> > >>> On Tue, 11 Aug 2015 11:30:03 +1000 > >>> Andrew Beekhof <[email protected]> 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. _______________________________________________ Users mailing list: [email protected] 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
