Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Wed, 19 Aug 2015 10:59:00 +0200 Jehan-Guillaume de Rorthais j...@dalibo.com 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 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 RD 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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
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: On 8 Aug 2015, at 1:14 am, Jehan-Guillaume de Rorthais j...@dalibo.com wrote: Hi Jan, On Fri, 7 Aug 2015 15:36:57 +0200 Jan Pokorný jpoko...@redhat.com 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 8/11/2015 11:01 AM, Jehan-Guillaume de Rorthais wrote: On Tue, 11 Aug 2015 06:42:37 +0200 Fabio M. Di Nitto fabbi...@fabbione.net 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ý jpoko...@redhat.com 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
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 fabbi...@fabbione.net 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 fabbi...@fabbione.net 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ý jpoko...@redhat.com 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
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Tue, 11 Aug 2015 11:30:03 +1000 Andrew Beekhof and...@beekhof.net wrote: On 8 Aug 2015, at 1:14 am, Jehan-Guillaume de Rorthais j...@dalibo.com wrote: Hi Jan, On Fri, 7 Aug 2015 15:36:57 +0200 Jan Pokorný jpoko...@redhat.com 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
On Tue, 11 Aug 2015 06:42:37 +0200 Fabio M. Di Nitto fabbi...@fabbione.net 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ý jpoko...@redhat.com 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 PostgreSQL core officialy (xml, autovacuum, FTS(tsearch), ...). But at least, PostgreSQL provides
Re: [ClusterLabs] [ClusterLabs Developers] Resource Agent language discussion
On Tue, 11 Aug 2015 11:15:47 +0200 Fabio M. Di Nitto fabbi...@fabbione.net 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 8 Aug 2015, at 1:14 am, Jehan-Guillaume de Rorthais j...@dalibo.com wrote: Hi Jan, On Fri, 7 Aug 2015 15:36:57 +0200 Jan Pokorný jpoko...@redhat.com 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 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
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
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
