[ClusterLabs Developers] Resource Agent language discussion

[Jan Pokorný]

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

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20150807/894b8bc4/attachment-0004.sig>