Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
> On 21 Aug 2015, at 2:21 am, Jehan-Guillaume de Rorthais
> wrote:
>
> On Thu, 20 Aug 2015 15:05:24 +1000
> Andrew Beekhof wrote:
>
>>
>>> On 19 Aug 2015, at 6:59 pm, Jehan-Guillaume de Rorthais
>>> wrote:
>>>
>>> On Mon, 17 Aug 2015 09:42:35 +1000
>>> Andrew Beekhof wrote:
>>>
> On 11 Aug 2015, at 5:34 pm, Jehan-Guillaume de Rorthais
> wrote:
>
> On Tue, 11 Aug 2015 11:30:03 +1000
> Andrew Beekhof 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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Thu, 20 Aug 2015 15:05:24 +1000
Andrew Beekhof wrote:
>
> > On 19 Aug 2015, at 6:59 pm, Jehan-Guillaume de Rorthais
> > wrote:
> >
> > On Mon, 17 Aug 2015 09:42:35 +1000
> > Andrew Beekhof wrote:
> >
> >>> On 11 Aug 2015, at 5:34 pm, Jehan-Guillaume de Rorthais
> >>> wrote:
> >>>
> >>> On Tue, 11 Aug 2015 11:30:03 +1000
> >>> Andrew Beekhof 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: Users@clust
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
> On 19 Aug 2015, at 6:59 pm, Jehan-Guillaume de Rorthais
> wrote:
>
> On Mon, 17 Aug 2015 09:42:35 +1000
> Andrew Beekhof wrote:
>
>>> On 11 Aug 2015, at 5:34 pm, Jehan-Guillaume de Rorthais
>>> wrote:
>>>
>>> On Tue, 11 Aug 2015 11:30:03 +1000
>>> Andrew Beekhof 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_Scrat
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Mon, 17 Aug 2015 09:42:35 +1000
Andrew Beekhof wrote:
>> On 11 Aug 2015, at 5:34 pm, Jehan-Guillaume de Rorthais
>> wrote:
>>
>> On Tue, 11 Aug 2015 11:30:03 +1000
>> Andrew Beekhof 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, 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?
* is there a chance a perl version of such library would be accepted upstream?
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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Wed, 19 Aug 2015 10:59:00 +0200 Jehan-Guillaume de Rorthais wrote: [...] > 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 About this topic, some quick stats shows we have a 40% smaller code than the existing RA (excluding comments) and 3x more comments. [...] > > - 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), ... Oh, and I forgot a big one: our RA is only compatible with PostgreSQL >= 9.3 ___ 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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
> On 11 Aug 2015, at 5:34 pm, Jehan-Guillaume de Rorthais > wrote: > > On Tue, 11 Aug 2015 11:30:03 +1000 > Andrew Beekhof wrote: > >> >>> On 8 Aug 2015, at 1:14 am, Jehan-Guillaume de Rorthais >>> wrote: >>> >>> Hi Jan, >>> >>> On Fri, 7 Aug 2015 15:36:57 +0200 >>> Jan Pokorný wrote: >>> On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: > Now, I would like to discuss about the language used to write a RA in > Pacemaker. I never seen discussion or page about this so far. it wasn't in such a "heretic :)" tone, but I tried to show that it is extremely hard (if not impossible in some instances) to write bullet-proof code in bash (or POSIX shell, for that matter) because it's so cumbersome to move from "whitespace-delimited words as a single argument" and "words as standalone arguments" back and forth, connected with quotation-desired/-counterproductive madness (what if one wants to indeed pass quotation marks as legitimate characters within the passed value, etc.) few months back: http://clusterlabs.org/pipermail/users/2015-May/000403.html (even on developers list, but with fewer replies and broken threading: http://clusterlabs.org/pipermail/developers/2015-May/23.html). >>> >>> Thanks for the links and history. You add some more argument to my points :) >>> > HINT: I don't want to discuss (neither troll about) what is the best > language. I would like to know why **ALL** the RA are written in > bash I would expect the original influence were the init scripts (as RAs are mostly just enriched variants to support more flexible configuration and better diagnostics back to the cluster stack), which in turn were born having simplicity and ease of debugging (maintainability) in mind. >>> >>> That sounds legitimate. And bash is still appropriate for some simple RA. >>> >>> But for the same ease of code debugging and maintainability arguments (and >>> many others), complexe RA shouldn't use shell as language. >> >> 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 :-) The first questions any maintainer is going to ask are: - why did you write a new one? - can we merge this with the old one? - can the new one replace the old one? (ie. full superset) 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. ___ 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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Tue, 11 Aug 2015 11:15:47 +0200 "Fabio M. Di Nitto" wrote: [...] > >> In most systems, all commands required to execute a RA in shell are > >> already cached in ram and requirements to re-run them are minimal (and > >> could save a system). > >> > >> with Perl, there was no caching that I could see (even executing the > >> command several times), with lots of I/O to load modules from disks. > > > > If hitting 10MB on memory or disk is a problem on your server, your RA is > > probably not your main problem by this time. > > That is a bad assumption that shouldn´t be done either directions. > > We could argue the other way around :) > > If loading 10MB of $fancy_language_script fails to stop a service that > is driving the server bad, vs loading 500k of shell that saves the node > to be fenced, then the language become a problem. Well, how much time a bash RA is buying you before the system eat the last 9.5MB compared to a $higher_language RA? The only situation you are safer is if your service stopped eating memory when hitting 98% of it (and your cache where your bash binaries were). But in this situation, the OOM killer is probably already lurking around, preparing to kill your service, calling its stonithd friend on the other node to join the party right after. ___ 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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Tue, 11 Aug 2015 06:42:37 +0200 "Fabio M. Di Nitto" wrote: >On 8/7/2015 5:14 PM, Jehan-Guillaume de Rorthais wrote: >> Hi Jan, >> >> On Fri, 7 Aug 2015 15:36:57 +0200 >> Jan Pokorný wrote: >> >>> On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: Now, I would like to discuss about the language used to write a RA in Pacemaker. I never seen discussion or page about this so far. >>> >>> it wasn't in such a "heretic :)" tone, but I tried to show that it >>> is extremely hard (if not impossible in some instances) to write >>> bullet-proof code in bash (or POSIX shell, for that matter) because >>> it's so cumbersome to move from "whitespace-delimited words as >>> a single argument" and "words as standalone arguments" back and forth, >>> connected with quotation-desired/-counterproductive madness >>> (what if one wants to indeed pass quotation marks as legitimate >>> characters within the passed value, etc.) few months back: >>> >>> http://clusterlabs.org/pipermail/users/2015-May/000403.html >>> (even on developers list, but with fewer replies and broken threading: >>> http://clusterlabs.org/pipermail/developers/2015-May/23.html). >> >> Thanks for the links and history. You add some more argument to my points :) >> HINT: I don't want to discuss (neither troll about) what is the best language. I would like to know why **ALL** the RA are written in bash >>> >>> I would expect the original influence were the init scripts (as RAs >>> are mostly just enriched variants to support more flexible >>> configuration and better diagnostics back to the cluster stack), >>> which in turn were born having simplicity and ease of debugging >>> (maintainability) in mind. >> >> That sounds legitimate. And bash is still appropriate for some simple RA. >> >> But for the same ease of code debugging and maintainability arguments (and >> many others), complexe RA shouldn't use shell as language. > > so beside the language you can/want to use, from a development > perspective you guys are probably right that in some cases, more complex > languages could be a better fit. > > But you forgot to position yourself as end user and the reason why we > currently use bash/shell. > > first of all, our end user is not necessarily a developer. Most of them > are in fact sysadmins and one common that sysadmins have is that they > know bash/shell. I understand that. However, most sysadmins know the basics of bash, maybe some advanced bash, to interact with the system. But how many of them are actually doing proper **development** in bash? Use arrays, escape parameters, protects against unwanted globing, use substitutions instead of cut/sed/awk/grep/whatever, check their return code, declare "typed" variable, mess with their scope, ...? Sysadmins are happy with bash for simple tasks/scripts or just doing sysadmin. When it comes to development, they turn to perl or python nowadays. If they want to open and debug a RA, this is not some sysadmin anymore, this is development. At least, I would expect published RA to be well tested and "production" ready, not having trivial bug easy to fix. > If needs arise to debug a RA, shell is pretty much the only common > denominator with our user base. But as a sysadmin who tries to write robust bash script and as a PostgreSQL DBA, if I open the pgsql RA agent, I become a bit nervous. Try to run shellcheck on the pgsql and mysql RA. Proper and robust bash development often require to use syntaxes, features and cautions a lot of people will not be familiar with. Worst, sometime you must stick outside of good practices: consider some optional args to a command you must not quote as instance... It just becomes quickly a headache. So all-in-all, as a sysadmin, watching at some RA code (not all of them) doesn't give me much more confidence about them. And reading the discussions pointed by Jan earlier in this thread confirm this feeling. > The other problem i see in using other languages is how they operate > under extreme conditions (memory pressure, disk I/O etc). > > Just for the fun of it, [...] > Granted, it´s an incredibly small test et all, but all I am trying to > say is that Cluster is supposed to be as reliable as possible under > extreme conditions. Ok, I understand this argument. Bash is reliable and lighter, so better fit for extreme condition. But then, I would expect the project to provide a C library as well. I'm not kidding, I understand bash is a good compromise. But as far as I can read the code and debug if needed, whatever the language. Again, this is development tasks. If I pick the PostgreSQL project, the engine can be extended using SQL, PL/PgSQL, python, perl, C, and many other languages (even shell), to add operators, types, functions/procedures, background worker (C only), ... People extending or using external modules are responsible to test and validate them. Sometime, when such a module is really useful, they are swallowed in the P
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Tue, 11 Aug 2015 11:30:03 +1000 Andrew Beekhof wrote: > > > On 8 Aug 2015, at 1:14 am, Jehan-Guillaume de Rorthais > > wrote: > > > > Hi Jan, > > > > On Fri, 7 Aug 2015 15:36:57 +0200 > > Jan Pokorný wrote: > > > >> On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: > >>> Now, I would like to discuss about the language used to write a RA in > >>> Pacemaker. I never seen discussion or page about this so far. > >> > >> it wasn't in such a "heretic :)" tone, but I tried to show that it > >> is extremely hard (if not impossible in some instances) to write > >> bullet-proof code in bash (or POSIX shell, for that matter) because > >> it's so cumbersome to move from "whitespace-delimited words as > >> a single argument" and "words as standalone arguments" back and forth, > >> connected with quotation-desired/-counterproductive madness > >> (what if one wants to indeed pass quotation marks as legitimate > >> characters within the passed value, etc.) few months back: > >> > >> http://clusterlabs.org/pipermail/users/2015-May/000403.html > >> (even on developers list, but with fewer replies and broken threading: > >> http://clusterlabs.org/pipermail/developers/2015-May/23.html). > > > > Thanks for the links and history. You add some more argument to my points :) > > > >>> HINT: I don't want to discuss (neither troll about) what is the best > >>> language. I would like to know why **ALL** the RA are written in > >>> bash > >> > >> I would expect the original influence were the init scripts (as RAs > >> are mostly just enriched variants to support more flexible > >> configuration and better diagnostics back to the cluster stack), > >> which in turn were born having simplicity and ease of debugging > >> (maintainability) in mind. > > > > That sounds legitimate. And bash is still appropriate for some simple RA. > > > > But for the same ease of code debugging and maintainability arguments (and > > many others), complexe RA shouldn't use shell as language. > > 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. ___ 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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
I'm butting in here by saying that I don't think that the performance discussion is very useful. Performance can always be improved, and by that logic everything should be hand-written in assembly. Correctness and maintainability should be of much higher importance. Premature optimization Besides, Bash isn't exactly the fastest choice out there. Best regards Alexander On Tue, Aug 11, 2015 at 11:15 AM, Fabio M. Di Nitto wrote: > > > On 8/11/2015 11:01 AM, Jehan-Guillaume de Rorthais wrote: > > On Tue, 11 Aug 2015 06:42:37 +0200 > > "Fabio M. Di Nitto" wrote: > >> On 8/7/2015 5:14 PM, Jehan-Guillaume de Rorthais wrote: > >>> Hi Jan, > >>> > >>> On Fri, 7 Aug 2015 15:36:57 +0200 > >>> Jan Pokorný wrote: > >>> > On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: > > Now, I would like to discuss about the language used to write a RA in > > Pacemaker. I never seen discussion or page about this so far. > > it wasn't in such a "heretic :)" tone, but I tried to show that it > is extremely hard (if not impossible in some instances) to write > bullet-proof code in bash (or POSIX shell, for that matter) because > it's so cumbersome to move from "whitespace-delimited words as > a single argument" and "words as standalone arguments" back and forth, > connected with quotation-desired/-counterproductive madness > (what if one wants to indeed pass quotation marks as legitimate > characters within the passed value, etc.) few months back: > > http://clusterlabs.org/pipermail/users/2015-May/000403.html > (even on developers list, but with fewer replies and broken threading: > http://clusterlabs.org/pipermail/developers/2015-May/23.html). > >>> > >>> Thanks for the links and history. You add some more argument to my > points :) > >>> > > HINT: I don't want to discuss (neither troll about) what is the best > > language. I would like to know why **ALL** the RA are written in > > bash > > I would expect the original influence were the init scripts (as RAs > are mostly just enriched variants to support more flexible > configuration and better diagnostics back to the cluster stack), > which in turn were born having simplicity and ease of debugging > (maintainability) in mind. > >>> > >>> That sounds legitimate. And bash is still appropriate for some simple > RA. > >>> > >>> But for the same ease of code debugging and maintainability arguments > (and > >>> many others), complexe RA shouldn't use shell as language. > >> > >> so beside the language you can/want to use, from a development > >> perspective you guys are probably right that in some cases, more complex > >> languages could be a better fit. > >> > >> But you forgot to position yourself as end user and the reason why we > >> currently use bash/shell. > >> > >> first of all, our end user is not necessarily a developer. Most of them > >> are in fact sysadmins and one common that sysadmins have is that they > >> know bash/shell. > > > > I understand that. However, most sysadmins know the basics of bash, > maybe some > > advanced bash, to interact with the system. But how many of them are > actually > > doing proper **development** in bash? Use arrays, escape parameters, > protects > > against unwanted globing, use substitutions instead of > > cut/sed/awk/grep/whatever, check their return code, declare "typed" > variable, > > mess with their scope, ...? > > > > Sysadmins are happy with bash for simple tasks/scripts or just doing > sysadmin. > > When it comes to development, they turn to perl or python nowadays. If > they > > want to open and debug a RA, this is not some sysadmin anymore, this is > > development. At least, I would expect published RA to be well tested and > > "production" ready, not having trivial bug easy to fix. > > > >> If needs arise to debug a RA, shell is pretty much the only common > >> denominator with our user base. > > > > But as a sysadmin who tries to write robust bash script and as a > PostgreSQL DBA, > > if I open the pgsql RA agent, I become a bit nervous. Try to run > shellcheck on > > the pgsql and mysql RA. > > > > Proper and robust bash development often require to use syntaxes, > features > > and cautions a lot of people will not be familiar with. Worst, sometime > you > > must stick outside of good practices: consider some optional args to a > > command you must not quote as instance... It just becomes quickly a > headache. > > > > So all-in-all, as a sysadmin, watching at some RA code (not all of them) > doesn't > > give me much more confidence about them. And reading the discussions > pointed by > > Jan earlier in this thread confirm this feeling. > > > >> The other problem i see in using other languages is how they operate > >> under extreme conditions (memory pressure, disk I/O etc). > >> > >> Just for the fun of it, > > [...] > > > >> Granted, it´s an incredibly small test et all, but all I am tr
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On 8/11/2015 11:01 AM, Jehan-Guillaume de Rorthais wrote: > On Tue, 11 Aug 2015 06:42:37 +0200 > "Fabio M. Di Nitto" wrote: >> On 8/7/2015 5:14 PM, Jehan-Guillaume de Rorthais wrote: >>> Hi Jan, >>> >>> On Fri, 7 Aug 2015 15:36:57 +0200 >>> Jan Pokorný wrote: >>> On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: > Now, I would like to discuss about the language used to write a RA in > Pacemaker. I never seen discussion or page about this so far. it wasn't in such a "heretic :)" tone, but I tried to show that it is extremely hard (if not impossible in some instances) to write bullet-proof code in bash (or POSIX shell, for that matter) because it's so cumbersome to move from "whitespace-delimited words as a single argument" and "words as standalone arguments" back and forth, connected with quotation-desired/-counterproductive madness (what if one wants to indeed pass quotation marks as legitimate characters within the passed value, etc.) few months back: http://clusterlabs.org/pipermail/users/2015-May/000403.html (even on developers list, but with fewer replies and broken threading: http://clusterlabs.org/pipermail/developers/2015-May/23.html). >>> >>> Thanks for the links and history. You add some more argument to my points :) >>> > HINT: I don't want to discuss (neither troll about) what is the best > language. I would like to know why **ALL** the RA are written in > bash I would expect the original influence were the init scripts (as RAs are mostly just enriched variants to support more flexible configuration and better diagnostics back to the cluster stack), which in turn were born having simplicity and ease of debugging (maintainability) in mind. >>> >>> That sounds legitimate. And bash is still appropriate for some simple RA. >>> >>> But for the same ease of code debugging and maintainability arguments (and >>> many others), complexe RA shouldn't use shell as language. >> >> so beside the language you can/want to use, from a development >> perspective you guys are probably right that in some cases, more complex >> languages could be a better fit. >> >> But you forgot to position yourself as end user and the reason why we >> currently use bash/shell. >> >> first of all, our end user is not necessarily a developer. Most of them >> are in fact sysadmins and one common that sysadmins have is that they >> know bash/shell. > > I understand that. However, most sysadmins know the basics of bash, maybe some > advanced bash, to interact with the system. But how many of them are actually > doing proper **development** in bash? Use arrays, escape parameters, protects > against unwanted globing, use substitutions instead of > cut/sed/awk/grep/whatever, check their return code, declare "typed" variable, > mess with their scope, ...? > > Sysadmins are happy with bash for simple tasks/scripts or just doing sysadmin. > When it comes to development, they turn to perl or python nowadays. If they > want to open and debug a RA, this is not some sysadmin anymore, this is > development. At least, I would expect published RA to be well tested and > "production" ready, not having trivial bug easy to fix. > >> If needs arise to debug a RA, shell is pretty much the only common >> denominator with our user base. > > But as a sysadmin who tries to write robust bash script and as a PostgreSQL > DBA, > if I open the pgsql RA agent, I become a bit nervous. Try to run shellcheck on > the pgsql and mysql RA. > > Proper and robust bash development often require to use syntaxes, features > and cautions a lot of people will not be familiar with. Worst, sometime you > must stick outside of good practices: consider some optional args to a > command you must not quote as instance... It just becomes quickly a headache. > > So all-in-all, as a sysadmin, watching at some RA code (not all of them) > doesn't > give me much more confidence about them. And reading the discussions pointed > by > Jan earlier in this thread confirm this feeling. > >> The other problem i see in using other languages is how they operate >> under extreme conditions (memory pressure, disk I/O etc). >> >> Just for the fun of it, > [...] > >> Granted, it´s an incredibly small test et all, but all I am trying to >> say is that Cluster is supposed to be as reliable as possible under >> extreme conditions. > > Ok, I understand this argument. Bash is reliable and lighter, so better fit > for > extreme condition. But then, I would expect the project to provide a C > library as well. I'm not kidding, I understand bash is a good compromise. But > as far as I can read the code and debug if needed, whatever the language. > Again, this is development tasks. > > If I pick the PostgreSQL project, the engine can be extended using SQL, > PL/PgSQL, python, perl, C, and many other languages (even shell), to add > operators, types, functio
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On 8/7/2015 5:14 PM, Jehan-Guillaume de Rorthais wrote: > Hi Jan, > > On Fri, 7 Aug 2015 15:36:57 +0200 > Jan Pokorný wrote: > >> On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: >>> Now, I would like to discuss about the language used to write a RA in >>> Pacemaker. I never seen discussion or page about this so far. >> >> it wasn't in such a "heretic :)" tone, but I tried to show that it >> is extremely hard (if not impossible in some instances) to write >> bullet-proof code in bash (or POSIX shell, for that matter) because >> it's so cumbersome to move from "whitespace-delimited words as >> a single argument" and "words as standalone arguments" back and forth, >> connected with quotation-desired/-counterproductive madness >> (what if one wants to indeed pass quotation marks as legitimate >> characters within the passed value, etc.) few months back: >> >> http://clusterlabs.org/pipermail/users/2015-May/000403.html >> (even on developers list, but with fewer replies and broken threading: >> http://clusterlabs.org/pipermail/developers/2015-May/23.html). > > Thanks for the links and history. You add some more argument to my points :) > >>> HINT: I don't want to discuss (neither troll about) what is the best >>> language. I would like to know why **ALL** the RA are written in >>> bash >> >> I would expect the original influence were the init scripts (as RAs >> are mostly just enriched variants to support more flexible >> configuration and better diagnostics back to the cluster stack), >> which in turn were born having simplicity and ease of debugging >> (maintainability) in mind. > > That sounds legitimate. And bash is still appropriate for some simple RA. > > But for the same ease of code debugging and maintainability arguments (and > many > others), complexe RA shouldn't use shell as language. so beside the language you can/want to use, from a development perspective you guys are probably right that in some cases, more complex languages could be a better fit. But you forgot to position yourself as end user and the reason why we currently use bash/shell. first of all, our end user is not necessarily a developer. Most of them are in fact sysadmins and one common that sysadmins have is that they know bash/shell. If needs arise to debug a RA, shell is pretty much the only common denominator with our user base. The other problem i see in using other languages is how they operate under extreme conditions (memory pressure, disk I/O etc). Just for the fun of it, I did some basic profiling of "hello world" in bash and perl. Please don´t take this as an attempt to start a "language" flame war here. I just want to explain differences on why shell vs others. Perl is at least 3 times slower than bash Perl uses at least 4/5 times more memory to execute the same command Granted, it´s an incredibly small test et all, but all I am trying to say is that Cluster is supposed to be as reliable as possible under extreme conditions. In most systems, all commands required to execute a RA in shell are already cached in ram and requirements to re-run them are minimal (and could save a system). with Perl, there was no caching that I could see (even executing the command several times), with lots of I/O to load modules from disks. So given that, is it worth rewriting the RA in another language (and what defines a "simple" vs "complex" ras from above)? or wouldn´t it better to just fix the current ones for stuff like escapes and handling of spaces in the options? Just 2c Fabio > >>> and if there's traps (hidden far in ocf-shellfuncs as instance) >>> to avoid if using a different language. And is it acceptable to >>> include new libs for other languages? >> >> https://github.com/ClusterLabs/resource-agents/blob/v3.9.6/doc/dev-guides/ra-dev-guide.txt#L33 >> doesn't make any assumption about the target language beside stating >> what's a common one. > > Yes, I know that page. But this dev guide focus on shell and have some > assumptions about ocf-shellfuncs. > > I'll take the same exemple than in my previous message, there's nothing > about the best practice for logging. In the "Script variables" section, some > comes from environment, others from ocf-shellfuncs. > >>> We rewrote the RA in perl, mostly because of me. I was bored with bash/sh >>> limitations AND syntax AND useless code complexity for some easy tasks AND >>> traps (return code etc). In my opinion, bash/sh are fine if you RA code is >>> short and simple. Which was mostly the case back in the time of heartbeat >>> which was stateless only. But it became a nightmare with multi-state agents >>> struggling with complexe code to fit with Pacemaker behavior. Have a look >>> to the mysql or pgsql agents. >>> >>> Moreover, with bash, I had some weird behaviors (timeouts) from the RA >>> between runuser/su/sudo and systemd/pamd some months ago. The three of them >>> have system implications or side effects deep in the system you need to >>> t
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
> On 8 Aug 2015, at 1:14 am, Jehan-Guillaume de Rorthais > wrote: > > Hi Jan, > > On Fri, 7 Aug 2015 15:36:57 +0200 > Jan Pokorný wrote: > >> On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: >>> Now, I would like to discuss about the language used to write a RA in >>> Pacemaker. I never seen discussion or page about this so far. >> >> it wasn't in such a "heretic :)" tone, but I tried to show that it >> is extremely hard (if not impossible in some instances) to write >> bullet-proof code in bash (or POSIX shell, for that matter) because >> it's so cumbersome to move from "whitespace-delimited words as >> a single argument" and "words as standalone arguments" back and forth, >> connected with quotation-desired/-counterproductive madness >> (what if one wants to indeed pass quotation marks as legitimate >> characters within the passed value, etc.) few months back: >> >> http://clusterlabs.org/pipermail/users/2015-May/000403.html >> (even on developers list, but with fewer replies and broken threading: >> http://clusterlabs.org/pipermail/developers/2015-May/23.html). > > Thanks for the links and history. You add some more argument to my points :) > >>> HINT: I don't want to discuss (neither troll about) what is the best >>> language. I would like to know why **ALL** the RA are written in >>> bash >> >> I would expect the original influence were the init scripts (as RAs >> are mostly just enriched variants to support more flexible >> configuration and better diagnostics back to the cluster stack), >> which in turn were born having simplicity and ease of debugging >> (maintainability) in mind. > > That sounds legitimate. And bash is still appropriate for some simple RA. > > But for the same ease of code debugging and maintainability arguments (and > many > others), complexe RA shouldn't use shell as language. 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. As always, the people doing the work get to make the rules. > >>> and if there's traps (hidden far in ocf-shellfuncs as instance) >>> to avoid if using a different language. And is it acceptable to >>> include new libs for other languages? >> >> https://github.com/ClusterLabs/resource-agents/blob/v3.9.6/doc/dev-guides/ra-dev-guide.txt#L33 >> doesn't make any assumption about the target language beside stating >> what's a common one. > > Yes, I know that page. But this dev guide focus on shell and have some > assumptions about ocf-shellfuncs. > > I'll take the same exemple than in my previous message, there's nothing > about the best practice for logging. In the "Script variables" section, some > comes from environment, others from ocf-shellfuncs. > >>> We rewrote the RA in perl, mostly because of me. I was bored with bash/sh >>> limitations AND syntax AND useless code complexity for some easy tasks AND >>> traps (return code etc). In my opinion, bash/sh are fine if you RA code is >>> short and simple. Which was mostly the case back in the time of heartbeat >>> which was stateless only. But it became a nightmare with multi-state agents >>> struggling with complexe code to fit with Pacemaker behavior. Have a look >>> to the mysql or pgsql agents. >>> >>> Moreover, with bash, I had some weird behaviors (timeouts) from the RA >>> between runuser/su/sudo and systemd/pamd some months ago. The three of them >>> have system implications or side effects deep in the system you need to >>> take care off. Using a language able to seteuid/setuid after forking is >>> much more natural and clean to drop root privileges and start the daemon >>> (PostgreSQL refuses to start as root and is not able to drop its privileges >>> to another system user itself). >> >> Other disadvantage of shell scripts is that frequently many processes >> are spawned for simple changes within the filesystem and for string >> parsing/reformatting, which in turn creates a dependency on plenty >> of external executables. > > True. Either you need to pipe multi small programs, forking all of them > (cat|grep|cut|...), sometime with different behavior depending on the system > or > use a complexe one most people don't want to hear anymore (sed, awk, perl, > ...). > In the later case, you not only have to master bash, but other languages as > well. > >>> Now, we are far to have a enterprise class certified code, our RA had its >>> very first tests passed successfully yesterday, but here is a quick >>> feedback. The downside of picking another language than bash/sh is that >>> there is no OCF module/library available for them. This is quite >>> inconvenient when you need to get system specifics variables or logging >>> shortcut only defined in ocf-shellfuncs (and I would guess patched by >>> packagers ?). >>> >>> As instance, I had to "capture" values of $HA_SBIN_DIR and $HA_RSCTMP from >>> m
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
Hi Jan, On Fri, 7 Aug 2015 15:36:57 +0200 Jan Pokorný wrote: > On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: > > Now, I would like to discuss about the language used to write a RA in > > Pacemaker. I never seen discussion or page about this so far. > > it wasn't in such a "heretic :)" tone, but I tried to show that it > is extremely hard (if not impossible in some instances) to write > bullet-proof code in bash (or POSIX shell, for that matter) because > it's so cumbersome to move from "whitespace-delimited words as > a single argument" and "words as standalone arguments" back and forth, > connected with quotation-desired/-counterproductive madness > (what if one wants to indeed pass quotation marks as legitimate > characters within the passed value, etc.) few months back: > > http://clusterlabs.org/pipermail/users/2015-May/000403.html > (even on developers list, but with fewer replies and broken threading: > http://clusterlabs.org/pipermail/developers/2015-May/23.html). Thanks for the links and history. You add some more argument to my points :) > > HINT: I don't want to discuss (neither troll about) what is the best > > language. I would like to know why **ALL** the RA are written in > > bash > > I would expect the original influence were the init scripts (as RAs > are mostly just enriched variants to support more flexible > configuration and better diagnostics back to the cluster stack), > which in turn were born having simplicity and ease of debugging > (maintainability) in mind. That sounds legitimate. And bash is still appropriate for some simple RA. But for the same ease of code debugging and maintainability arguments (and many others), complexe RA shouldn't use shell as language. > > and if there's traps (hidden far in ocf-shellfuncs as instance) > > to avoid if using a different language. And is it acceptable to > > include new libs for other languages? > > https://github.com/ClusterLabs/resource-agents/blob/v3.9.6/doc/dev-guides/ra-dev-guide.txt#L33 > doesn't make any assumption about the target language beside stating > what's a common one. Yes, I know that page. But this dev guide focus on shell and have some assumptions about ocf-shellfuncs. I'll take the same exemple than in my previous message, there's nothing about the best practice for logging. In the "Script variables" section, some comes from environment, others from ocf-shellfuncs. > > We rewrote the RA in perl, mostly because of me. I was bored with bash/sh > > limitations AND syntax AND useless code complexity for some easy tasks AND > > traps (return code etc). In my opinion, bash/sh are fine if you RA code is > > short and simple. Which was mostly the case back in the time of heartbeat > > which was stateless only. But it became a nightmare with multi-state agents > > struggling with complexe code to fit with Pacemaker behavior. Have a look > > to the mysql or pgsql agents. > > > > Moreover, with bash, I had some weird behaviors (timeouts) from the RA > > between runuser/su/sudo and systemd/pamd some months ago. The three of them > > have system implications or side effects deep in the system you need to > > take care off. Using a language able to seteuid/setuid after forking is > > much more natural and clean to drop root privileges and start the daemon > > (PostgreSQL refuses to start as root and is not able to drop its privileges > > to another system user itself). > > Other disadvantage of shell scripts is that frequently many processes > are spawned for simple changes within the filesystem and for string > parsing/reformatting, which in turn creates a dependency on plenty > of external executables. True. Either you need to pipe multi small programs, forking all of them (cat|grep|cut|...), sometime with different behavior depending on the system or use a complexe one most people don't want to hear anymore (sed, awk, perl, ...). In the later case, you not only have to master bash, but other languages as well. > > Now, we are far to have a enterprise class certified code, our RA had its > > very first tests passed successfully yesterday, but here is a quick > > feedback. The downside of picking another language than bash/sh is that > > there is no OCF module/library available for them. This is quite > > inconvenient when you need to get system specifics variables or logging > > shortcut only defined in ocf-shellfuncs (and I would guess patched by > > packagers ?). > > > > As instance, I had to "capture" values of $HA_SBIN_DIR and $HA_RSCTMP from > > my perl code. > > There could be a shell wrapper that would put these values into the > environment and then executed the target itself for its disposal > (generic solution for arbitrary executable). That's not applicable > for "procedural knowledge" (logging, etc.), though, as you mention > below. Yes. What should we do next? Should we spin off an "ocf-perl-common" module from our agent and feed it with such pieces ported from ocf-shellfuncs?
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On 07/08/15 09:36 AM, Jan Pokorný wrote: > Hello, > > [adding users list as I think there's an overlap] > > On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: >> Now, I would like to discuss about the language used to write a RA in >> Pacemaker. >> I never seen discussion or page about this so far. > > it wasn't in such a "heretic :)" tone, but I tried to show that it > is extremely hard (if not impossible in some instances) to write > bullet-proof code in bash (or POSIX shell, for that matter) because > it's so cumbersome to move from "whitespace-delimited words as > a single argument" and "words as standalone arguments" back and forth, > connected with quotation-desired/-counterproductive madness > (what if one wants to indeed pass quotation marks as legitimate > characters within the passed value, etc.) few months back: > > http://clusterlabs.org/pipermail/users/2015-May/000403.html > (even on developers list, but with fewer replies and broken threading: > http://clusterlabs.org/pipermail/developers/2015-May/23.html). > >> HINT: I don't want to discuss (neither troll about) what is the best >> language. I would like to know why **ALL** the RA are written in >> bash > > I would expect the original influence were the init scripts (as RAs > are mostly just enriched variants to support more flexible > configuration and better diagnostics back to the cluster stack), > which in turn were born having simplicity and ease of debugging > (maintainability) in mind. > >> and if there's traps (hidden far in ocf-shellfuncs as instance) >> to avoid if using a different language. And is it acceptable to >> include new libs for other languages? > > https://github.com/ClusterLabs/resource-agents/blob/v3.9.6/doc/dev-guides/ra-dev-guide.txt#L33 > doesn't make any assumption about the target language beside stating > what's a common one. > >> We rewrote the RA in perl, mostly because of me. I was bored with bash/sh >> limitations AND syntax AND useless code complexity for some easy tasks AND >> traps >> (return code etc). In my opinion, bash/sh are fine if you RA code is short >> and simple. Which was mostly the case back in the time of heartbeat which was >> stateless only. But it became a nightmare with multi-state agents struggling >> with complexe code to fit with Pacemaker behavior. Have a look to the mysql >> or >> pgsql agents. >> >> Moreover, with bash, I had some weird behaviors (timeouts) from the RA >> between >> runuser/su/sudo and systemd/pamd some months ago. The three of them have >> system >> implications or side effects deep in the system you need to take care off. >> Using >> a language able to seteuid/setuid after forking is much more natural and >> clean >> to drop root privileges and start the daemon (PostgreSQL refuses to start as >> root and is not able to drop its privileges to another system user itself). > > Other disadvantage of shell scripts is that frequently many processes > are spawned for simple changes within the filesystem and for string > parsing/reformatting, which in turn creates a dependency on plenty > of external executables. > >> Now, we are far to have a enterprise class certified code, our RA had its >> very first tests passed successfully yesterday, but here is a quick feedback. >> The downside of picking another language than bash/sh is that there is no >> OCF module/library available for them. This is quite inconvenient when you >> need >> to get system specifics variables or logging shortcut only defined in >> ocf-shellfuncs (and I would guess patched by packagers ?). >> >> As instance, I had to "capture" values of $HA_SBIN_DIR and $HA_RSCTMP from my >> perl code. > > There could be a shell wrapper that would put these values into the > environment and then executed the target itself for its disposal > (generic solution for arbitrary executable). That's not applicable > for "procedural knowledge" (logging, etc.), though, as you mention > below. > >> Another exemple, our perl RA is only logging to syslog presently. We >> will probably have to rewrite the ocf_log/ha_log/ha_debug in perl >> before publishing the final code. Any tip about this ? >> >> At some point, to have a clean, portable and OS agnostic code, I wonder how >> much code we will have to port from ocf-shellfuncs to perl... Allow me to add, uselessly; perl! <3 -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? ___ 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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
Hello, [adding users list as I think there's an overlap] On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote: > Now, I would like to discuss about the language used to write a RA in > Pacemaker. > I never seen discussion or page about this so far. it wasn't in such a "heretic :)" tone, but I tried to show that it is extremely hard (if not impossible in some instances) to write bullet-proof code in bash (or POSIX shell, for that matter) because it's so cumbersome to move from "whitespace-delimited words as a single argument" and "words as standalone arguments" back and forth, connected with quotation-desired/-counterproductive madness (what if one wants to indeed pass quotation marks as legitimate characters within the passed value, etc.) few months back: http://clusterlabs.org/pipermail/users/2015-May/000403.html (even on developers list, but with fewer replies and broken threading: http://clusterlabs.org/pipermail/developers/2015-May/23.html). > HINT: I don't want to discuss (neither troll about) what is the best > language. I would like to know why **ALL** the RA are written in > bash I would expect the original influence were the init scripts (as RAs are mostly just enriched variants to support more flexible configuration and better diagnostics back to the cluster stack), which in turn were born having simplicity and ease of debugging (maintainability) in mind. > and if there's traps (hidden far in ocf-shellfuncs as instance) > to avoid if using a different language. And is it acceptable to > include new libs for other languages? https://github.com/ClusterLabs/resource-agents/blob/v3.9.6/doc/dev-guides/ra-dev-guide.txt#L33 doesn't make any assumption about the target language beside stating what's a common one. > We rewrote the RA in perl, mostly because of me. I was bored with bash/sh > limitations AND syntax AND useless code complexity for some easy tasks AND > traps > (return code etc). In my opinion, bash/sh are fine if you RA code is short > and simple. Which was mostly the case back in the time of heartbeat which was > stateless only. But it became a nightmare with multi-state agents struggling > with complexe code to fit with Pacemaker behavior. Have a look to the mysql or > pgsql agents. > > Moreover, with bash, I had some weird behaviors (timeouts) from the RA between > runuser/su/sudo and systemd/pamd some months ago. The three of them have > system > implications or side effects deep in the system you need to take care off. > Using > a language able to seteuid/setuid after forking is much more natural and clean > to drop root privileges and start the daemon (PostgreSQL refuses to start as > root and is not able to drop its privileges to another system user itself). Other disadvantage of shell scripts is that frequently many processes are spawned for simple changes within the filesystem and for string parsing/reformatting, which in turn creates a dependency on plenty of external executables. > Now, we are far to have a enterprise class certified code, our RA had its > very first tests passed successfully yesterday, but here is a quick feedback. > The downside of picking another language than bash/sh is that there is no > OCF module/library available for them. This is quite inconvenient when you > need > to get system specifics variables or logging shortcut only defined in > ocf-shellfuncs (and I would guess patched by packagers ?). > > As instance, I had to "capture" values of $HA_SBIN_DIR and $HA_RSCTMP from my > perl code. There could be a shell wrapper that would put these values into the environment and then executed the target itself for its disposal (generic solution for arbitrary executable). That's not applicable for "procedural knowledge" (logging, etc.), though, as you mention below. > Another exemple, our perl RA is only logging to syslog presently. We > will probably have to rewrite the ocf_log/ha_log/ha_debug in perl > before publishing the final code. Any tip about this ? > > At some point, to have a clean, portable and OS agnostic code, I wonder how > much code we will have to port from ocf-shellfuncs to perl... -- Jan (Poki) pgpQv1WZWRDWY.pgp Description: PGP signature ___ 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
