>>> Jan Pokorný <jpoko...@redhat.com> schrieb am 10.09.2019 um 17:38 in Nachricht <20190910153832.gj29...@redhat.com>: > On 10/09/19 08:06 +0200, Ulrich Windl wrote: >>>>> Ken Gaillot <kgail...@redhat.com> schrieb am 09.09.2019 um 17:14 >>>>> in Nachricht >>>>> <9e51c562c74e52c3b9e5f85576210bf83144fae7.ca...@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 _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/