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