[ClusterLabs] Antw: Re: Why is last-lrm-refresh part of the CIB config?

[Ulrich Windl]

>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 12.09.2019 um 11:48 in
Nachricht
<20190912094840.GL29300 at redhat.com>:
> On 12/09/19 09:27 +0200, Ulrich Windl wrote:
>>>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 10.09.2019 um 17:38
>>>>> in Nachricht <20190910153832.GJ29300 at redhat.com>:
>>> 
>>> Just looking at how to provisionally satisfy the needs here, I can
>>> suggest this "one-liner" as a filter to let the to-archive-copies
>>> through (depending on the aposteriori diff):
>>> 
>>>   { xsltproc - <(cibadmin -Q) | cat; } <<EOF
>>>   <xsl:stylesheet version="1.0" 
>>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>>>     <xsl:template match="@*|node()">
>>>       <xsl:copy>
>>>         <xsl:apply-templates select="@*|node()"/>
>>>       </xsl:copy>
>>>     </xsl:template>
>>>     <xsl:template match="status|nvpair[@name='last-lrm-refresh']
>>>                          |text()[preceding-sibling::*[
>>>                            name() = 'status'
>>>                            or
>>>                            name() = 'nvpair' and @name='last-lrm-refresh'
>>>                          ]]"/>
>>>   </xsl:stylesheet>
>>>   EOF
>>> 
>> 
>> [...]
>>> plain POSIX shell.  The additional complexity stems from the desire
>>> so as not to keep blank lines where anything got filtered out.
>> 
>> Actually it "eats up" the line break and identation before
>> </cluster_property_set> also, like here:
>> 
>>        <nvpair name="stonith-enabled" value="true"
>> id="cib-bootstrap-options-stonith-enabled"/>
>>        <nvpair name="placement-strategy" value="utilization"
>> id="cib-bootstrap-options-placement-strategy"/>
>> -      <nvpair id="cib-bootstrap-options-last-lrm-refresh"
>> name="last-lrm-refresh" value="1567945827"/>
>> -      <nvpair name="maintenance-mode" value="false"
>> id="cib-bootstrap-options-maintenance-mode"/>
>> -    </cluster_property_set>
>> +      <nvpair name="maintenance-mode" value="false"
>> id="cib-bootstrap-options-maintenance-mode"/></cluster_property_set>
>>    </crm_config>
>>    <nodes>
> 
> Good spot :-)
> 
> Untested fix (you'll get the idea, check just the first match element
> on the preceding-sibling axis):

Those, who can, can ;-) (fix confirmed):
--- /tmp/cib2   2019-09-12 09:21:31.427435264 +0200
+++ /tmp/cib1   2019-09-12 12:18:28.115354718 +0200
@@ -1,3 +1,4 @@
+<?xml version="1.0"?>
 <configuration>
   <crm_config>
     <cluster_property_set id="cib-bootstrap-options">
@@ -7,7 +8,6 @@
       <nvpair id="cib-bootstrap-options-cluster-name" name="cluster-name"
value="cluster3"/>
       <nvpair name="stonith-enabled" value="true"
id="cib-bootstrap-options-stonith-enabled"/>
       <nvpair name="placement-strategy" value="utilization"
id="cib-bootstrap-options-placement-strategy"/>
-      <nvpair id="cib-bootstrap-options-last-lrm-refresh"
name="last-lrm-refresh" value="1567945827"/>
       <nvpair name="maintenance-mode" value="false"
id="cib-bootstrap-options-maintenance-mode"/>
     </cluster_property_set>
   </crm_config>

> 
>   { xsltproc - <(cibadmin -Q) | cat; } <<EOF
>   <xsl:stylesheet version="1.0" 
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>     <xsl:template match="@*|node()">
>       <xsl:copy>
>         <xsl:apply-templates select="@*|node()"/>
>       </xsl:copy>
>     </xsl:template>
>     <xsl:template match="status|nvpair[@name='last-lrm-refresh']
>                          |text()[preceding-sibling::*[1][
>                            name() = 'status'
>                            or
>                            name() = 'nvpair' and @name='last-lrm-refresh'
>                          ]]"/>
>   </xsl:stylesheet>
>   EOF
> 
> Some wiggling around this idea would certainly lead to desired results.
> OTOH, if you backfeed that output back to crm (to get the reinstating
> sequence), whitespaces are pretty irrelevant, allowing for vast
> simplification.
> 
> And when you are after the actual XML diff, text-based diff is
> a *bad choice* in general anyway.  An identical XML content can be

I agree that there are many ways to represent one XML content. Fortunately
cibadmin does not put everything in one line ;-)

> expressed with a countless number of variations in the serialized
> form (plain text projection), and you are really interested in the
> semantical identity only.  That text-based diff more or less work
> is rather an implementation detail not to be relied upon across
> SW updates, etc. (libxml2-specific environment variables could affect
> the output as well!).  There are multiple "XML diff" tools, perhaps
> even crm_diff would do (but specialities like comments, processing
> instructions etc. may not work well with it, admittedly they probably
> won't be present to begin with).

I'm hoping on the constant (same locale) "same input, same program, same
output" ;-)

> 
> -- 
> Poki