Bug 1571157 - [RFE] Not able to change zone of nodes after we configure it
Summary: [RFE] Not able to change zone of nodes after we configure it
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: heketi
Version: cns-3.9
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: John Mulligan
QA Contact: Nitin Goyal
Depends On:
Blocks: OCS-3.11.1-devel-triage-done 1707226
TreeView+ depends on / blocked
Reported: 2018-04-24 08:24 UTC by Nitin Goyal
Modified: 2019-08-13 15:17 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-08-13 15:17:25 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Nitin Goyal 2018-04-24 08:24:23 UTC
Description of problem: We are not able to change the zones of nodes after installing the CNS. We should provide this feature, So we can change zone of nodes at any time.

Version-Release number of selected component (if applicable):6.0.0-11

Additional info: There is only one way to change this i.e. we need to uninstall the all setup then we need to configure it again with new changes.

Comment 4 Raghavendra Talur 2019-01-23 20:35:10 UTC
Summarizing the requirement:
We need a mechanism to change zones of nodes. To restrict the scope, it would not reconfigure existing volumes but is a valid ask if the user did not assign zones to nodes in first place.

Comment 5 Michael Adam 2019-01-24 00:23:28 UTC
Zones can be changed by dumping the db and editing the json and re-importing the db.

But as Talur pointed out: we should not be reconfiguring zones, because it might invalidate the already created volumes that made use of the original zones!

Since there is a way via a db dump and i don't see the urgent need, I'm closing this as wontfix. Please re-open if you disagree.

Comment 6 daniel 2019-04-13 05:53:37 UTC

I suppose that your suggested way would then require a customer to raise a case, attach db dump, we change it and then customer imports changed db, right? 
If so, that would at least require that no volume actions, i. e. create, update or delete are done which is keeping heketi mode in local to prevent this is done which means a downtime for storage service.
I am not sure if this would be a desirable way, hence reopening this for reconsideration

Comment 7 Michael Adam 2019-04-13 09:45:17 UTC

Of course it can be done, and technically the request is 100% legitimate. But what's the main motivation for changing zones? What are the use case scenarios?

I can imagine these:

- The customer has originally not payed attention to zones but now wants to define those.
- A node (or a group of nodes) has moved from one availability zone to another.
  (Special case: An existing zone has been split into two or more zones.)

But how common is this? Is this expected to happen once a week or once a year among our customers?

And there are some considerations:

- Especially with the new strict zone more of brick placement, changing the zone of a node might render existing volumes degraded.
- Usually, the zones are rather static among existing nodes. If this is a very rare operation (see above), are the efforts to implement (and document) it justified at this point? (Happy to prioritize it if there's big demand.)

Note You need to log in before you can comment on or make changes to this bug.