Christine Caulfield napsal(a):
On 12/08/14 14:41, Jan Friesse wrote:
Christine Caulfield napsal(a):
On 11/08/14 09:36, Jan Friesse wrote:
Christine Caulfield napsal(a):
On 11/08/14 09:17, Jan Friesse wrote:
Christine Caulfield napsal(a):
On 11/08/14 08:59, Jan Friesse wrote:
Chrissie,
On 11/08/14 07:29, Jan Friesse wrote:
Chrissie,
patch looks generally good, but is there a reason to add new
library
call instead of tracking "quorum.wait_for_all" and if set to 0,
execute
code very similar to
message_handler_req_lib_votequorum_cancel_wait_for_all?
Yes. The point is not to clear wait_for_all itself, that's a
configuration option and we are not changing it - just the runtime
wait
state. The config option needs to remain enabled for the next time
nodes
Yes. But user can call corosync-cmapctl to change this variable. We
don't need to (or want to) to change it via reload. Very similar
thing
is happening with expected votes. Take a look to
ed63c812afc15fc68ebd3363845a63f5c945623e (and this was actually
inspiration for what I'm suggesting). wait_for_all is totally same.
Allow natural selection. Dynamic change of "config" (but not
stored to
config file).
No, it's not changing the config - even dynamically. It's changing a
state inside corosync, not even a dynamic configuration parameter.
Sure
wait_for_all_status is NOT the same thing as quorum.wait_for_all -
not
even slightly. wait_for_all needs to remain set after this command
(whatever it turns out to be) for the next time a node goes down,
we do
not want to have to wait for a reload for that to happen.
It will. cmap is NOT stored back into config, so wait_for_all WILL
remain set after this command for the next time a node down (are you
talking about local node, right?). No reload needs to happen.
Indeed, but it's still stored in cmap - and I don't want
wait_for_all to
change in cmap. If that was what I wanted then that's what I would
have
done.
wait_for_all is not what I'm changing here. It's the internal status
that says we are currently waiting - not that we should wait in
future.
Oh. So you are talking about config integrity (current cmap reflect
what
is in the config) and not about "technical" problem. It makes sense
then.
But I think changing runtime.votequorum.wait_for_all_status give big
problem with recursion (maybe quite hard to solve, especially on
non-local node (node which initiated change)). If so, you can then try
to use similar method as triggering blackbox creation (set something
like runtime.votequorum.cancel_wait_for_all)
Honza
OK try 3..
This one just uses a cmap key to trigger the cancel. Although it looks a
lot neater than the last one (mainly due to the lack of the new API
call) I'm not totally happy using a cmap variable as an edge-trigger.
Nice small patch.
Still, it's a small patch and keeps the thing undocumented - which is
probably a plus ;-)
Uh. Would you make too much angry if I will ask you for (short)
documentation in cmap_keys man page?
I've added a man page entry:
Chrissie
Perfect,
go ahead and push it.
Thanks,
Honza
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss
