Bug 1571157

Summary: [RFE] Not able to change zone of nodes after we configure it
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Nitin Goyal <nigoyal>
Component: heketiAssignee: John Mulligan <jmulligan>
Status: CLOSED WONTFIX QA Contact: Nitin Goyal <nigoyal>
Severity: low Docs Contact:
Priority: unspecified    
Version: cns-3.9CC: dmoessne, dyocum, hchiramm, jmulligan, kramdoss, madam, rhs-bugs, rtalur, sankarshan, storage-qa-internal
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-13 15:17:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1641915, 1707226    

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 
Michael,

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 
Daniel,

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.)