[WIP] API to Enable/Disable peer

[rishubhjain]

Issue: #1085

[prashanthpai]

@rishubhjain

The original use-case is to disable the peer only for the purpose of volume creation. A general Disabled field in peer object is too broad and might confuse users. Is there any other way to maintain this disabled state in devices/smartvol/DVP APIs ? Or can you come up with a better name than disabled ?

cc @aravindavk

[atinmu]

My understanding is it can't be a boolean. from operator requirements we may have to maintain different state of a peer. Please refer https://github.com/gluster/anthill/pull/36/files#diff-0 for more details.

…

On Tue, Aug 7, 2018 at 10:55 AM Prashanth Pai ***@***.***> wrote: @rishubhjain <https://github.com/rishubhjain> The original use-case is to disable the peer only for the purpose of volume creation. A general Disabled field in peer object is too broad and might confuse users. Is there any other way to maintain this disabled state in devices/smartvol/DVP APIs ? Or can you come up with a better name than disabled ? cc @aravindavk <https://github.com/aravindavk> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1121 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGp7mNfhedPzLPyQWWRKJ4C5GQP1W4Pcks5uOSTCgaJpZM4VtHy1> .

[aravindavk]

Is there any other way to maintain this disabled state in devices/smartvol/DVP APIs ? Or can you come up with a better name than disabled ?

Devices already has this field. Peer state is required for peer maintenance activities.

[prashanthpai]

If the peer maintenance activities are performed by operator (external entity), the onus is on the operator to store this either in it's own state/storage or store it as arbitrary value using glusterd2's peer metadata API as there's no actionable item/task (for glusterd2) related to this state.

[prashanthpai]

cc @JohnStrunk

[atinmu]

@JohnStrunk @prashanthpai did we manage to reach to a conclusion on this?

[JohnStrunk]

This discussion happened while I was on vacation. Sorry @atinmu and @prashanthpai.

The operator is the admin's conduit to controlling the cluster. It must be possible to:

• Mark a node as "in maintenance" (aka "quiesced" in the anthill doc). While quiesced, that node shouldn't be used for IVP, nor should (automatic) migrations of bricks from that node be initiated as a consequence of the node being down. (I realize the auto migration isn't implemented.)
• Mark a node that should be decommissioned. Once marked, it should no longer be eligible for IVP, and a (to-be-written) plugin should migrate all the bricks to elsewhere in the cluster.

Whether we have a specific API call that sets a node as "disabled" or we just have a set of well-known node-level tags, I think the above are possible. The anthill doc provides a possible method of using labels to do the necessary handshaking to implement the above operations. The closest to the "disabled" state proposed here is shouldQuiesce in that doc.