>>> 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 > > 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) _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/