Re: [ClusterLabs] Why is last-lrm-refresh part of the CIB config?
On 12/09/19 09:27 +0200, Ulrich Windl wrote:
Jan Pokorný schrieb am 10.09.2019 um 17:38
in Nachricht <20190910153832.gj29...@redhat.com>:
>>
>> 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; } <> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform;>
>>
>>
>>
>>
>>
>>
>>
>> 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
> also, like here:
>
> id="cib-bootstrap-options-stonith-enabled"/>
> id="cib-bootstrap-options-placement-strategy"/>
> - name="last-lrm-refresh" value="1567945827"/>
> - id="cib-bootstrap-options-maintenance-mode"/>
> -
> + id="cib-bootstrap-options-maintenance-mode"/>
>
>
Good spot :-)
Untested fix (you'll get the idea, check just the first match element
on the preceding-sibling axis):
{ xsltproc - <(cibadmin -Q) | cat; }
EOF
Some wiggling around this idea would certainly lead to desired results.
OTOH, if you backfeed that output back to crm (to get the reinstating
sequence), whitespaces are pretty irrelevant, allowing for vast
simplification.
And when you are after the actual XML diff, text-based diff is
a *bad choice* in general anyway. An identical XML content can be
expressed with a countless number of variations in the serialized
form (plain text projection), and you are really interested in the
semantical identity only. That text-based diff more or less work
is rather an implementation detail not to be relied upon across
SW updates, etc. (libxml2-specific environment variables could affect
the output as well!). There are multiple "XML diff" tools, perhaps
even crm_diff would do (but specialities like comments, processing
instructions etc. may not work well with it, admittedly they probably
won't be present to begin with).
--
Poki
pgptzqob81yLk.pgp
Description: PGP signature
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Why is last-lrm-refresh part of the CIB config?
On 10/09/19 08:06 +0200, Ulrich Windl wrote:
Ken Gaillot 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:
>>> ‑ >> name="last‑lrm‑refresh" value="1566194010"/>
>>> + >> 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
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)
pgp7NH4QgsiJF.pgp
Description: PGP signature
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Why is last-lrm-refresh part of the CIB config?
On Mon, 2019-09-09 at 11:06 +0200, Ulrich Windl wrote: > Hi! > > 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: > - name="last-lrm-refresh" value="1566194010"/> > + name="last-lrm-refresh" value="1567945827"/> > > I don't see a reason for having that. Can someone explain? > > Regards, > Ulrich 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. 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. -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Why is last-lrm-refresh part of the CIB config?
Hi! 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: - + I don't see a reason for having that. Can someone explain? Regards, Ulrich ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
