<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 05/15/2015 02:37 PM, Jan Pokorný
wrote:<br>
</div>
<blockquote cite="mid:20150515203737.GB7411@redhat.com" type="cite">
<pre wrap="">On 13/05/15 11:44 +0200, Lars Ellenberg wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, May 12, 2015 at 07:23:36AM -0600, Alan Robertson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This is not a problem in the OCF API, but in the pcs command.
There is no issue with having spaces in environment variables.
It's the pcs command that's doing you dirty here...
</pre>
</blockquote>
</blockquote>
<pre wrap="">I am afraid I sense some short-circuiting here. I should have provided
more details to preempt blaming pcs for everything, as it only served
to demonstrate the point (and the bugs at the end served to show somewhat
relevant issues with handling doublequotes, e.g., in case explicit quoting
of white-space contained parameter value becomes recommended practice
~ C1.-second option/"suboptimal").
To compensate it now, clarification follows:
# pcs resource create mysql-test1 ocf:heartbeat:mysql \
'config=/mnt/foo/mysql/config final.cnf'
will lead to the following nvpair in CIB:
<nvpair id="mysql-test1-instance_attributes-config"
name="config"
value="/mnt/foo/mysql/config final.cnf"/>
and, likewise,
# pcs resource create mysql-test2 ocf:heartbeat:mysql \
'config="/mnt/foo/mysql/config final.cnf"'
to
<nvpair id="mysql-test2-instance_attributes-config"
name="config"
value=""/mnt/foo/mysql/config final.cnf""/>
So there is _no_ issue on pcs side so far.
Also Pacemaker will pass the environment variables in a correct manner
(yes, it's perfectly valid to have spaces there).
Only later in chain, some assumptions may be broken in such a case:
</pre>
<blockquote type="cite">
<pre wrap="">In this case it is also the mysql RA (and helper functions)
that do not properly quote.
<a class="moz-txt-link-freetext" href="https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/mysql-common.sh#L108">https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/mysql-common.sh#L108</a>
ff.
if [ ! -f $OCF_RESKEY_config ]; then
Well, sure, that breaks.
</pre>
</blockquote>
<pre wrap="">Sure, I know :) But this is not an isolated case at all (see below) and
that's why I wanted to bring this up.
</pre>
<blockquote type="cite">
<pre wrap="">But Alan is right, of course, this is not a problem with the OCF API.
</pre>
</blockquote>
<pre wrap="">I hope I haven't implied the contrary -- I only offered a prospect
of possibly solving this issue on the API level by either excluding
spaces from a parameter value domain altogether (A./"dull") or setting
rules how to enquote spec-contained parameter values explictly
(C1.-second option/"suboptimal"). This is the only relevance to OCF.
Oh, there's also a possibility for more granular parameter value domain/
data type restrictions akin to what you can achieve in Relax NG
(mentioned that at the HA Summit in Brno) -- parameters could
determine themselves whether space in string is supported or not
and the validators in management tools could enforce that.
Apparently, OCF standard would have to be amended first, but
I anticipate this would be optional, non-disruptive extension.</pre>
</blockquote>
They should just support spaces. Otherwise the agents are broken.
Fix them.<br>
<br>
Don't change the spec to deal with the fact that some people aren't
very good at writing shell scripts. This is a general, common, and
well-known "gotcha" in writing shell scripts.<br>
<br>
If you want to fix something, then fix the <b>documentation</b> on
how to write them. I wonder if one can fix the agent test code to
ensure that parameters with spaces are given? [probably not]. But
it could certainly offer a reminder to make sure they are tested
with spaces in them.<br>
<br>
-- Alan Robertson<br>
<a class="moz-txt-link-abbreviated" href="mailto:alanr@unix.sh">alanr@unix.sh</a><br>
</body>
</html>