Revision 601908d0
| ID | 601908d0f5e528a3ddfc7cefb2bbfd9f99e7a39f |
Rework the node modify for mc-demotion
The current code in LUSetNodeParms regarding the demotion from master
candidate role is complicated and duplicates the code in ConfigWriter,
where such decisions should be made. Furthermore, we still cannot demote
nodes (not even with force), if other regular nodes exist.
This patch adds a new opcode attribute ‘auto_promote’, and changes the
decision tree as follows:
- if the node will be set to offline or drained or explicitly demoted
from master candidate, and this parameter is set, then we lock all
nodes in ExpandNames()
- later, in CheckPrereq(), if the node is
indeed a master candidate, and the future state (as computed via
GetMasterCandidateStats with the current node in the exception list)
has fewer nodes than it should, and we didn't lock all nodes, we exit
with an exception
- in Exec, if we locked all nodes, we do a AdjustCandidatePool() run, to
ensure nodes are locked as needed (we do it before updating the node
to remove a warning, and prevent the situation that if the LU fails
between these, we're not left with an inconsistent state)
Note that in Exec we run the AdjustCP irrespective of any node state
change (just based on lock status), so we might simplify the CheckPrereq
even more by not checking the future state, basically requiring
auto_promote/lock_all for master candidates, since the case where we
have more than needed master candidates is rarer; OTOH, this would prevent
manual promotion ahead of time of another node, which is why I didn't
choose this way.
Signed-off-by: Iustin Pop <iustin@google.com>
Reviewed-by: Guido Trotter <ultrotter@google.com>
Reviewed-by: Michael Hanselmann <hansmi@google.com>
Files
- added
- modified
- copied
- renamed
- deleted