[ClusterLabs] Antw: Re: Antw: Re: Antw: Re: pacemaker resources under systemd
>>> Andrei Borzenkov schrieb am 12.09.2019 um 15:00 in Nachricht : > On Thu, Sep 12, 2019 at 3:45 PM Ulrich Windl > wrote: >> >> >>> Andrei Borzenkov schrieb am 12.09.2019 um 14:21 in >> Nachricht >> : >> > On Thu, Sep 12, 2019 at 12:40 PM Ulrich Windl >> > wrote: >> >> >> >> Hi! >> >> >> >> I just discovered an unpleasant side‑effect of this: >> >> SLES has "zypper ps" to show processes that use obsoleted binaries. Now if >> >> > any >> >> resource binary was replaced, zypper suggests to restart pacemaker (which >> is >> >> nonsense, of course). >> >> >> >> Example: >> >> # zypper ps >> >> The following running processes use deleted files: >> >> >> >> PID| PPID | UID | User | Command | Service | Files >> >> >> > >> ‑‑‑+‑‑‑+‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑ >> > ‑‑ >> >> 2558 | 92480 | 0 | root | isredir (deleted) | pacemaker | >> >> /usr/bin/isredir (deleted) >> >> >> >> The file definitely is not a part of pacemaker! >> >> >> > >> > Neither zypper tells you that it is. All that zypper tells you is that >> > binary of some process that was started as part of pacemaker *SERVICE* >> > was deleted and that if you want to refresh it and ensure that process >> > is using updated binary you need to restart *SERVICE* pacemaker. Which >> >> That is exactly the point: You DO NOT need to restart pacemaker; it is >> sufficient to restart the corresponding resource. >> >> > is absolutely correct. Restarting pacemaker service makes sure >> > everything used by pacemaker is up to date. That pacemaker is capable >> > of restarting only some processes is not known to zypper. While it >> > sure is possible to extend zypper to recognize pacemaker, parse >> > current configuration and suggest to restart specific resource, this >> > time is probably better spent somewhere else. >> >> You absolutely miss the point: > > I do not. > >> In a 24x7 environment (a classic cluster >> application) restarting pacemaker means that every resource is stopped and >> restarted. If you do it in maintenance mode, the resources will not be >> restarted, but also the problem will not go away. Not restarting pacemaker > is >> worth the time! >> > > This is common misconception. Your 24x7 environment must have planned > maintenance windows exactly so you can do maintenance that requires > stopping and starting process/services/systems. And in such critical > environments updates are not installed at arbitrary times, but during > these maintenance windows. > > But sure, if zypper can do better, that's fine. I am just not sure > whether zypper developers can be reached on this forum ... Maybe it can be fixed in pacemaker's unit file also. I'don't know. As said before, it feels just wrong to me to run all cliuster resources in the pacemaker slice. Regards, Ulrich ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Antw: Re: Antw: Re: pacemaker resources under systemd
On Thu, Sep 12, 2019 at 3:45 PM Ulrich Windl wrote: > > >>> Andrei Borzenkov schrieb am 12.09.2019 um 14:21 in > Nachricht > : > > On Thu, Sep 12, 2019 at 12:40 PM Ulrich Windl > > wrote: > >> > >> Hi! > >> > >> I just discovered an unpleasant side-effect of this: > >> SLES has "zypper ps" to show processes that use obsoleted binaries. Now if > > > any > >> resource binary was replaced, zypper suggests to restart pacemaker (which > is > >> nonsense, of course). > >> > >> Example: > >> # zypper ps > >> The following running processes use deleted files: > >> > >> PID| PPID | UID | User | Command | Service | Files > >> > > > ---+---+-+---+---+---+--- > > -- > >> 2558 | 92480 | 0 | root | isredir (deleted) | pacemaker | > >> /usr/bin/isredir (deleted) > >> > >> The file definitely is not a part of pacemaker! > >> > > > > Neither zypper tells you that it is. All that zypper tells you is that > > binary of some process that was started as part of pacemaker *SERVICE* > > was deleted and that if you want to refresh it and ensure that process > > is using updated binary you need to restart *SERVICE* pacemaker. Which > > That is exactly the point: You DO NOT need to restart pacemaker; it is > sufficient to restart the corresponding resource. > > > is absolutely correct. Restarting pacemaker service makes sure > > everything used by pacemaker is up to date. That pacemaker is capable > > of restarting only some processes is not known to zypper. While it > > sure is possible to extend zypper to recognize pacemaker, parse > > current configuration and suggest to restart specific resource, this > > time is probably better spent somewhere else. > > You absolutely miss the point: I do not. > In a 24x7 environment (a classic cluster > application) restarting pacemaker means that every resource is stopped and > restarted. If you do it in maintenance mode, the resources will not be > restarted, but also the problem will not go away. Not restarting pacemaker is > worth the time! > This is common misconception. Your 24x7 environment must have planned maintenance windows exactly so you can do maintenance that requires stopping and starting process/services/systems. And in such critical environments updates are not installed at arbitrary times, but during these maintenance windows. But sure, if zypper can do better, that's fine. I am just not sure whether zypper developers can be reached on this forum ... ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Antw: Re: pacemaker resources under systemd
On Thu, Sep 12, 2019 at 12:40 PM Ulrich Windl wrote: > > Hi! > > I just discovered an unpleasant side-effect of this: > SLES has "zypper ps" to show processes that use obsoleted binaries. Now if any > resource binary was replaced, zypper suggests to restart pacemaker (which is > nonsense, of course). > > Example: > # zypper ps > The following running processes use deleted files: > > PID| PPID | UID | User | Command | Service | Files > ---+---+-+---+---+---+- > 2558 | 92480 | 0 | root | isredir (deleted) | pacemaker | > /usr/bin/isredir (deleted) > > The file definitely is not a part of pacemaker! > Neither zypper tells you that it is. All that zypper tells you is that binary of some process that was started as part of pacemaker *SERVICE* was deleted and that if you want to refresh it and ensure that process is using updated binary you need to restart *SERVICE* pacemaker. Which is absolutely correct. Restarting pacemaker service makes sure everything used by pacemaker is up to date. That pacemaker is capable of restarting only some processes is not known to zypper. While it sure is possible to extend zypper to recognize pacemaker, parse current configuration and suggest to restart specific resource, this time is probably better spent somewhere else. > Regards, > Ulrich > > > >>> Jan Pokorný schrieb am 27.08.2019 um 16:22 in > Nachricht > <20190827142256.ga26...@redhat.com>: > > On 27/08/19 15:27 +0200, Ulrich Windl wrote: > >> Systemd think he's the boss, doing what he wants: Today I noticed that all > >> resources are run inside control group "pacemaker.service" like this: > >> ├─pacemaker.service > >> │ ├─ 26582 isredir-ML1: listening on 172.20.17.238/12503 (2/1) > >> │ ├─ 26601 /usr/bin/perl -w /usr/sbin/ldirectord > /etc/ldirectord/mail.conf > > start > >> │ ├─ 26628 ldirectord tcp:172.20.17.238:25 > >> │ ├─ 28963 isredir-DS1: handling 172.20.16.33/10475 -- 172.20.17.200/389 > >> │ ├─ 40548 /usr/sbin/pacemakerd -f > >> │ ├─ 40550 /usr/lib/pacemaker/cib > >> │ ├─ 40551 /usr/lib/pacemaker/stonithd > >> │ ├─ 40552 /usr/lib/pacemaker/lrmd > >> │ ├─ 40553 /usr/lib/pacemaker/attrd > >> │ ├─ 40554 /usr/lib/pacemaker/pengine > >> │ ├─ 40555 /usr/lib/pacemaker/crmd > >> │ ├─ 53948 isredir-DS2: handling 172.20.16.33/10570 -- 172.20.17.201/389 > >> │ ├─ 92472 isredir-DS1: listening on 172.20.17.204/12511 (13049/3) > >> ... > >> > >> (that "isredir" stuff is my own resource that forks processes and creates > >> threads on demand, thus modifying process (and thread) titles to help > >> understanding what's going on...) > >> > >> My resources are started via OCF RA (shell script), not a systemd unit. > >> > >> Wouldn't it make much more sense if each resource would run in its > >> own control group? > > > > While listing like above may be confusing, the main problem perhaps > > is that all the resource restrictions you specify in pacemaker service > > file will be accounted to the mix of stack-native and stack-managed > > resources (unless when of systemd class), hence making all those > > containment features and supervision of systemd rather unusable, since > > there's no tight (vs. rather open-ended) blackbox to reason about. > > > > There have been some thoughts that pacemaker could become the > > delegated controller of its own delegated cgroup subtrees in the > > past, however. > > > > There is a nice document detailing various possibilities, but > > also looks pretty overwhelming on the first look: > > https://systemd.io/CGROUP_DELEGATION > > Naively, i-like-continents integration option there looks most > > appealing to me at this point. > > > > If anyone has insights into cgroups and how it pairs with systemd > > and could pair with pacemaker, please do speak up, it could be > > a great help in sketching the design in this area. > > > >> I mean: If systemd thinks everything MUST run in some control group, > >> why not pick the "correct " one? Having the pacemaker infrastructure > >> in the same control group as all the resources seems to be a bad > >> idea IMHO. > > > > No doubts it is suboptimal. > > > >> The other "discussable feature" are "high PIDs" like "92472". While port > >> numbers are still 16 bit (in IPv4 at least), I see little sense in having > >> millions of processes or threads. > > > > Have seen your questioning this at the systemd ML, but wouldn't think > > of any kind of inconveniences in that regard, modulo pre-existing real > > bugs. It actually slightly helps to unbreak firm-guarantees-lacking > > design based on PID liveness (risk of process ID recycling is still > > better than downright crazy "process grep'ing", totally unsuitable > > when chroots, PID namespaces or containers rooted on that very host > > get into the picture, but not much better otherwise[1]!). > > > > [1] https://lists.clusterlabs.org/pipermail/users/2019-July/025978.html > > > > -- > > Jan
[ClusterLabs] Antw: Re: Why is last-lrm-refresh part of the CIB config?
>>> Jan Pokorný schrieb am 12.09.2019 um 11:48 in
Nachricht
<20190912094840.gl29...@redhat.com>:
> 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):
Those, who can, can ;-) (fix confirmed):
--- /tmp/cib2 2019-09-12 09:21:31.427435264 +0200
+++ /tmp/cib1 2019-09-12 12:18:28.115354718 +0200
@@ -1,3 +1,4 @@
+
@@ -7,7 +8,6 @@
-
>
> { 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
I agree that there are many ways to represent one XML content. Fortunately
cibadmin does not put everything in one line ;-)
> 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).
I'm hoping on the constant (same locale) "same input, same program, same
output" ;-)
>
> --
> Poki
___
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 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/
[ClusterLabs] Antw: Re: pacemaker resources under systemd
Hi! I just discovered an unpleasant side-effect of this: SLES has "zypper ps" to show processes that use obsoleted binaries. Now if any resource binary was replaced, zypper suggests to restart pacemaker (which is nonsense, of course). Example: # zypper ps The following running processes use deleted files: PID| PPID | UID | User | Command | Service | Files ---+---+-+---+---+---+- 2558 | 92480 | 0 | root | isredir (deleted) | pacemaker | /usr/bin/isredir (deleted) The file definitely is not a part of pacemaker! Regards, Ulrich >>> Jan Pokorný schrieb am 27.08.2019 um 16:22 in Nachricht <20190827142256.ga26...@redhat.com>: > On 27/08/19 15:27 +0200, Ulrich Windl wrote: >> Systemd think he's the boss, doing what he wants: Today I noticed that all >> resources are run inside control group "pacemaker.service" like this: >> ├─pacemaker.service >> │ ├─ 26582 isredir-ML1: listening on 172.20.17.238/12503 (2/1) >> │ ├─ 26601 /usr/bin/perl -w /usr/sbin/ldirectord /etc/ldirectord/mail.conf > start >> │ ├─ 26628 ldirectord tcp:172.20.17.238:25 >> │ ├─ 28963 isredir-DS1: handling 172.20.16.33/10475 -- 172.20.17.200/389 >> │ ├─ 40548 /usr/sbin/pacemakerd -f >> │ ├─ 40550 /usr/lib/pacemaker/cib >> │ ├─ 40551 /usr/lib/pacemaker/stonithd >> │ ├─ 40552 /usr/lib/pacemaker/lrmd >> │ ├─ 40553 /usr/lib/pacemaker/attrd >> │ ├─ 40554 /usr/lib/pacemaker/pengine >> │ ├─ 40555 /usr/lib/pacemaker/crmd >> │ ├─ 53948 isredir-DS2: handling 172.20.16.33/10570 -- 172.20.17.201/389 >> │ ├─ 92472 isredir-DS1: listening on 172.20.17.204/12511 (13049/3) >> ... >> >> (that "isredir" stuff is my own resource that forks processes and creates >> threads on demand, thus modifying process (and thread) titles to help >> understanding what's going on...) >> >> My resources are started via OCF RA (shell script), not a systemd unit. >> >> Wouldn't it make much more sense if each resource would run in its >> own control group? > > While listing like above may be confusing, the main problem perhaps > is that all the resource restrictions you specify in pacemaker service > file will be accounted to the mix of stack-native and stack-managed > resources (unless when of systemd class), hence making all those > containment features and supervision of systemd rather unusable, since > there's no tight (vs. rather open-ended) blackbox to reason about. > > There have been some thoughts that pacemaker could become the > delegated controller of its own delegated cgroup subtrees in the > past, however. > > There is a nice document detailing various possibilities, but > also looks pretty overwhelming on the first look: > https://systemd.io/CGROUP_DELEGATION > Naively, i-like-continents integration option there looks most > appealing to me at this point. > > If anyone has insights into cgroups and how it pairs with systemd > and could pair with pacemaker, please do speak up, it could be > a great help in sketching the design in this area. > >> I mean: If systemd thinks everything MUST run in some control group, >> why not pick the "correct " one? Having the pacemaker infrastructure >> in the same control group as all the resources seems to be a bad >> idea IMHO. > > No doubts it is suboptimal. > >> The other "discussable feature" are "high PIDs" like "92472". While port >> numbers are still 16 bit (in IPv4 at least), I see little sense in having >> millions of processes or threads. > > Have seen your questioning this at the systemd ML, but wouldn't think > of any kind of inconveniences in that regard, modulo pre-existing real > bugs. It actually slightly helps to unbreak firm-guarantees-lacking > design based on PID liveness (risk of process ID recycling is still > better than downright crazy "process grep'ing", totally unsuitable > when chroots, PID namespaces or containers rooted on that very host > get into the picture, but not much better otherwise[1]!). > > [1] https://lists.clusterlabs.org/pipermail/users/2019-July/025978.html > > -- > Jan (Poki) ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Antw: Re: Why is last-lrm-refresh part of the CIB config?
>>> Jan Pokorný 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 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
>
[...]
> 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:
-
-
-
+
Regards,
Ulrich
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Antw: Re: Why is last-lrm-refresh part of the CIB config?
>>> Jan Pokorný 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 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.
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/
