[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
> 
> Above, "cat" is only for demonstration of how to further extend your
> pipeline (you can directly ground those flying data into a file
> instead).  It relies on bash extension (process substitution) over
> plain POSIX shell.  The additional complexity stems from the desire
> so as not to keep blank lines where anything got filtered out.

Hi!

You proved that you're a master of BASH ;-)
Of course I could filter the undesired attribute, but when "backing up" the
CIB's configuration setting, I'd prefer an unmodified version.

In case it's not clear what I'm talking about:
Assume you have some configuration where resource A is started; call it "C1".
Then stop A, call configuration "C2"
Finally staring A again, call it "C3".

What I'd like to see is simply that "C1" is equal to "C3".

Another interesting side-note (from "crm configure show"):
 property cib-bootstrap-options: \
        have-watchdog=true \
-       dc-version="1.1.19+20180928.0d2680780-1.8-1.1.19+20180928.0d2680780"
\
+      
dc-version="1.1.19+20181105.ccd6b5b10-3.10.1-1.1.19+20181105.ccd6b5b10" \
        cluster-infrastructure=corosync \
        cluster-name=cluster3 \
        stonith-enabled=true \
        placement-strategy=utilization \
-       last-lrm-refresh=1566194010 \
+       last-lrm-refresh=1567945827 \
        maintenance-mode=false

Here, there is a diff of the DC version and the last_lrm_refresh. It was
caused by a node reboot causing the DC to be re-elected on a node with a newer
pacemaker. Does it make sense to store the DC version in the CIB when not
storing the DC node? Maybe the dc-version should be in the status section.

Regards,
Ulrich

> 
> Hope this helps for now.
> 
> -- 
> Jan (Poki)