<div dir="ltr"><div>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.</div><div><br></div><div>Best regards</div><div><br></div><div>Alexander</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 11, 2015 at 11:15 AM, Fabio M. Di Nitto <span dir="ltr"><<a href="mailto:fabbione@fabbione.net" target="_blank">fabbione@fabbione.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 8/11/2015 11:01 AM, Jehan-Guillaume de Rorthais wrote:<br>
<div><div class="h5">> On Tue, 11 Aug 2015 06:42:37 +0200<br>
> "Fabio M. Di Nitto" <<a href="mailto:fabbione@fabbione.net">fabbione@fabbione.net</a>> wrote:<br>
>> On 8/7/2015 5:14 PM, Jehan-Guillaume de Rorthais wrote:<br>
>>> Hi Jan,<br>
>>><br>
>>> On Fri, 7 Aug 2015 15:36:57 +0200<br>
>>> Jan Pokorný <<a href="mailto:jpokorny@redhat.com">jpokorny@redhat.com</a>> wrote:<br>
>>><br>
>>>> On 07/08/15 12:09 +0200, Jehan-Guillaume de Rorthais wrote:<br>
>>>>> Now, I would like to discuss about the language used to write a RA in<br>
>>>>> Pacemaker. I never seen discussion or page about this so far.<br>
>>>><br>
>>>> it wasn't in such a "heretic :)" tone, but I tried to show that it<br>
>>>> is extremely hard (if not impossible in some instances) to write<br>
>>>> bullet-proof code in bash (or POSIX shell, for that matter) because<br>
>>>> it's so cumbersome to move from "whitespace-delimited words as<br>
>>>> a single argument" and "words as standalone arguments" back and forth,<br>
>>>> connected with quotation-desired/-counterproductive madness<br>
>>>> (what if one wants to indeed pass quotation marks as legitimate<br>
>>>> characters within the passed value, etc.) few months back:<br>
>>>><br>
>>>> <a href="http://clusterlabs.org/pipermail/users/2015-May/000403.html" rel="noreferrer" target="_blank">http://clusterlabs.org/pipermail/users/2015-May/000403.html</a><br>
>>>> (even on developers list, but with fewer replies and broken threading:<br>
>>>> <a href="http://clusterlabs.org/pipermail/developers/2015-May/000023.html" rel="noreferrer" target="_blank">http://clusterlabs.org/pipermail/developers/2015-May/000023.html</a>).<br>
>>><br>
>>> Thanks for the links and history. You add some more argument to my points :)<br>
>>><br>
>>>>> HINT: I don't want to discuss (neither troll about) what is the best<br>
>>>>> language. I would like to know why **ALL** the RA are written in<br>
>>>>> bash<br>
>>>><br>
>>>> I would expect the original influence were the init scripts (as RAs<br>
>>>> are mostly just enriched variants to support more flexible<br>
>>>> configuration and better diagnostics back to the cluster stack),<br>
>>>> which in turn were born having simplicity and ease of debugging<br>
>>>> (maintainability) in mind.<br>
>>><br>
>>> That sounds legitimate. And bash is still appropriate for some simple RA.<br>
>>><br>
>>> But for the same ease of code debugging and maintainability arguments (and<br>
>>> many others), complexe RA shouldn't use shell as language.<br>
>><br>
>> so beside the language you can/want to use, from a development<br>
>> perspective you guys are probably right that in some cases, more complex<br>
>> languages could be a better fit.<br>
>><br>
>> But you forgot to position yourself as end user and the reason why we<br>
>> currently use bash/shell.<br>
>><br>
>> first of all, our end user is not necessarily a developer. Most of them<br>
>> are in fact sysadmins and one common that sysadmins have is that they<br>
>> know bash/shell.<br>
><br>
</div></div>> I understand that. However, most sysadmins know the basics of bash, maybe some<br>
> advanced bash, to interact with the system. But how many of them are actually<br>
> doing proper **development** in bash? Use arrays, escape parameters, protects<br>
> against unwanted globing, use substitutions instead of<br>
> cut/sed/awk/grep/whatever, check their return code, declare "typed" variable,<br>
> mess with their scope, ...?<br>
><br>
> Sysadmins are happy with bash for simple tasks/scripts or just doing sysadmin.<br>
> When it comes to development, they turn to perl or python nowadays. If they<br>
> want to open and debug a RA, this is not some sysadmin anymore, this is<br>
> development. At least, I would expect published RA to be well tested and<br>
> "production" ready, not having trivial bug easy to fix.<br>
<span class="">><br>
>> If needs arise to debug a RA, shell is pretty much the only common<br>
>> denominator with our user base.<br>
><br>
</span>> But as a sysadmin who tries to write robust bash script and as a PostgreSQL DBA,<br>
> if I open the pgsql RA agent, I become a bit nervous. Try to run shellcheck on<br>
> the pgsql and mysql RA.<br>
><br>
> Proper and robust bash development often require to use syntaxes, features<br>
> and cautions a lot of people will not be familiar with. Worst, sometime you<br>
> must stick outside of good practices: consider some optional args to a<br>
> command you must not quote as instance... It just becomes quickly a headache.<br>
><br>
> So all-in-all, as a sysadmin, watching at some RA code (not all of them) doesn't<br>
> give me much more confidence about them. And reading the discussions pointed by<br>
> Jan earlier in this thread confirm this feeling.<br>
<span class="">><br>
>> The other problem i see in using other languages is how they operate<br>
>> under extreme conditions (memory pressure, disk I/O etc).<br>
>><br>
>> Just for the fun of it,<br>
</span>> [...]<br>
<span class="">><br>
>> Granted, it´s an incredibly small test et all, but all I am trying to<br>
>> say is that Cluster is supposed to be as reliable as possible under<br>
>> extreme conditions.<br>
><br>
</span>> Ok, I understand this argument. Bash is reliable and lighter, so better fit for<br>
> extreme condition. But then, I would expect the project to provide a C<br>
> library as well. I'm not kidding, I understand bash is a good compromise. But<br>
> as far as I can read the code and debug if needed, whatever the language.<br>
> Again, this is development tasks.<br>
><br>
> If I pick the PostgreSQL project, the engine can be extended using SQL,<br>
> PL/PgSQL, python, perl, C, and many other languages (even shell), to add<br>
> operators, types, functions/procedures, background worker (C only), ... People<br>
> extending or using external modules are responsible to test and validate them.<br>
> Sometime, when such a module is really useful, they are swallowed in the<br>
> PostgreSQL core officialy (xml, autovacuum, FTS(tsearch), ...). But at least,<br>
> PostgreSQL provides API and libraries for these languages.<br>
><br>
> Considering robustness and extreme condition, database and clustering solutions<br>
> share the same needs and attention.<br>
><br>
> Note that 3 RA are using perl from bash for some more complex (though really<br>
> simple) tasks: apache-conf.sh, nginx and pgsql. As long as perl has been loaded,<br>
> why not writing the whole RA in perl? ;-)<br>
<span class="">><br>
>> In most systems, all commands required to execute a RA in shell are<br>
>> already cached in ram and requirements to re-run them are minimal (and<br>
>> could save a system).<br>
>><br>
>> with Perl, there was no caching that I could see (even executing the<br>
>> command several times), with lots of I/O to load modules from disks.<br>
><br>
</span>> If hitting 10MB on memory or disk is a problem on your server, your RA is<br>
> probably not your main problem by this time.<br>
<br>
That is a bad assumption that shouldn´t be done either directions.<br>
<br>
We could argue the other way around :)<br>
<br>
If loading 10MB of $fancy_language_script fails to stop a service that<br>
is driving the server bad, vs loading 500k of shell that saves the node<br>
to be fenced, then the language become a problem.<br>
<span class="HOEnZb"><font color="#888888"><br>
Fabio<br>
</font></span><span class="im HOEnZb"><br>
><br>
>> So given that, is it worth rewriting the RA in another language (and<br>
>> what defines a "simple" vs "complex" ras from above)? or wouldn´t it<br>
>> better to just fix the current ones for stuff like escapes and handling<br>
>> of spaces in the options?<br>
><br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div>