Chrissie,
Christine Caulfield napsal(a):
On 20/03/15 10:26, Jan Friesse wrote:
Chrissie,
nice idea but I have two comments.
1. Nodes without nodeid (so auto generated nodeid) are not checked. It
can happen that user enters nodeid which collides with auto generated
nodeid. In practice not very important, but still make sense to make it
right.
I've had a look at this and I'm not sure it's feasible. There's no
reasonable way I can think of defining a node that's in the nodelist
that shouldn't be there because it clashes with the active list.
I was actually thinking about following scenario:
nodelist {
node {
ring0_addr: 192.168.1.1
}
node {
ring0_addr: 192.168.1.2
nodeid: decimal form of 192.168.1.1
}
}
So there are two nodes with same nodeid.
Does this fall into one of three scenarios you've wrote?
Because scenario I've described is not properly detected in corosync
(and it's one of big todo) and corosync will crash. I believe your patch
will be more complete if it would be able to detect this case.
Regards,
Honza
There are three scenerios that I can see:
1) node xxxxxxxx is in the nodelist and in the active list. That sounds
correct to me, maybe someone legitimised a existing autogenerated nodeid.
2) node xxxxxxxx is in the nodelist and not in the active list. Also OK
as the node might not be up yet.
3) node xxxxxxxx is in the active list and not in the nodelist. This is
the nearest I can come up with to a bad configuration but it's nothing
to do with adding the wrong node to the nodelist. It's about NOT having
nodes in the nodelist that should be there and can never be caught by
examining the nodelist. It should be caught much earlier if at all.
Does this make sense?
2. We don't have mechanism to exit corosync on reload but during startup
it may make sense to simply exit corosync if there are nodes with
duplicate nodeids. It's evidently mistake and people tends to NOT read
logs.
This behaves as expected as I said in an earlier email, of course
Chrissie
Regards,
Honza
Christine Caulfield napsal(a):
Having duplicate nodeids in corosync.conf can play havoc with a cluster,
so (as suggested by someone on this list) here is some code to check
that all nodeids are unique.
It logs all non-unique nodeids to syslog, but only the last is reported
on the command-line to the user which should be enough to get them to
check further.
Signed-off-by: Christine Caulfield <ccaulfie@xxxxxxxxxx>
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
