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

[Jan Pokorný]

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.

Hope this helps for now.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190910/7c28b828/attachment.sig>