Change the meaning of call_node_start_master
Currently, backend.StartMaster (the function behind this RPC call) will activate the master IP and then, if the start_daemons parameter is true, it will also activate the master role. While this works, it has two issues: - first, it will activate the master IP unconditionally, even if this node will not start the master daemon due to missing votes - second, the activation of the IP is done twice if start_daemons is true, because the master daemon does its own activation too This behaviour seems to be unmodified since Summer 2008, so probably any rationale on why this is done in two places is forgotten. The patch changes so that this function does *either* IP activation or master role activation but not both. So the IP will be activated only once (from the master daemon or from LURenameCluster), and it will only be done if the masterd got enough votes for startup. I can see only one downside to this change: if masterd won't actually start (due to missing votes), RAPI will still start, and without the master IP activated. But this is no worse than before, when both RAPI was running and the IP was activated. Note that the behaviour of StopMaster remains the same, as noone else does the IP removal. Signed-off-by:Iustin Pop <iustin@google.com> Reviewed-by:
René Nussbaumer <rn@google.com>
Loading
Please register or sign in to comment