Description of problem:
An update of ccsd with a cluster.conf version that is equal to or less
than the current verion in memory, that node will revert all the way
back to version "1" (or what ever version the original file was) and
be out of sync with the rest of the cluster which is left at the
current verion in memory.
Version-Release number of selected component (if applicable):
Expected Results: It should just fail, keep the current verion in
memory, and write out a reject file for the one attempting to update
I can't reproduce this...
What version of xml lib are you running?
> xml2-config --version
[root@morph-01 root]# xml2-config --version
Ok, in order to reproduce this you need to do the following:
all> cman_tool join
one> inc by 2 config_version of cluster.conf
one> killall -HUP ccsd
two> dec by 1 config_version of cluster.conf
two> killall -HUP ccsd
two> observe bug
Doing all the single node steps on a specific machine will not cause the bug.
Please verify that this is true.
You do not have to inc the version by 2, any bump in the version will
work. Also you don't have to dec by one, you just have to send ccsd a
-HUP with a version equal to or less then what's currently in mem.
Also, when it goes back to the original version, it is just that. All
changes that may have been made to the file when updated previously
You are correct in that doing all the single node steps on a specific
machine will not cause the bug.
The second node was not reading the new file into memory until it was
needed, this offered a window of time to change the file before it
could be read.
This cause two types of bugs. The first (this one) was that if the
file was changed and an update was attempted, a failure of that update
would result in the in-memory (stale) copy being written to disk.
The second bug that this could cause is if the file was changed on
disk before it was read into memory, nodes could become out of sync.
Updating version to the right level in the defects. Sorry for the storm.