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

[Ulrich Windl]

>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 10.09.2019 um 17:38 in
Nachricht
<20190910153832.GJ29300 at redhat.com>:
> On 10/09/19 08:06 +0200, Ulrich Windl wrote:
>>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 09.09.2019 um 17:14
>>>>> in Nachricht
>>>>> <9e51c562c74e52c3b9e5f85576210bf83144fae7.camel at redhat.com>:
>>> On Mon, 2019‑09‑09 at 11:06 +0200, Ulrich Windl wrote:
>>>> In recent pacemaker I see that last‑lrm‑refresh is included in the
>>>> CIB config (crm_config/cluster_property_set), so CIBs are "different"
>>>> when they are actually the same.
>>>> 
>>>> Example diff:
>>>> ‑      <nvpair id="cib‑bootstrap‑options‑last‑lrm‑refresh" 
> name="last‑lrm‑refresh" value="1566194010"/>
>>>> +      <nvpair id="cib‑bootstrap‑options‑last‑lrm‑refresh" 
> name="last‑lrm‑refresh" value="1567945827"/>
>>>> 
>>>> I don't see a reason for having that. Can someone explain?
>>> 
>>> New transitions (re‑calculation of cluster status) are triggered by
>>> changes in the CIB. last‑lrm‑refresh isn't really special in any way,
>>> it's just a value that can be changed arbitrarily to trigger a new
>>> transition when nothing "real" is changing.
>> 
>> But wouldn't it be more appropriate in the status section of the CIB then?
>> Also isn't pacemaker working with CIB digests anyway? And there is the
>> three-number CIB versioning, too.
>> 
>>> I'm not sure what would actually be setting it these days; its use has
>>> almost vanished in recent code. I think it was used more commonly for
>>> clean‑ups in the past.
>> 
>> My guess is that a crm configure did such a change.
>> 
>> Why I care: I'm archiving CIB configuration (but not status) changes
>> (that is the CIBs and the diffs); so I don't like such dummy changes
>> ;-)
> 
> 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>

Regards,
Ulrich