• Iustin Pop's avatar
    Rework the node modify for mc-demotion · 601908d0
    Iustin Pop authored
    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: default avatarIustin Pop <iustin@google.com>
    Reviewed-by: default avatarGuido Trotter <ultrotter@google.com>
    Reviewed-by: default avatarMichael Hanselmann <hansmi@google.com>
opcodes.py 19 KB