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/000023.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