[ClusterLabs Developers] Resource Agent language discussion

Fri Aug 7 15:14:39 UTC 2015

Hi Jan,

On Fri, 7 Aug 2015 15:36:57 +0200
Jan Pokorný <jpokorny at 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/000023.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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20150807/a56610e2/attachment-0004.sig>