Cannot detach root volume from instance (to attach a different volume)

[Schad]

In objection of https://review.openstack.org/#/c/75552/ I have use cases to be able to detach the (none-ephemeral) root volume from an instance/ a server to be able to attach a different volume.

Using the following (undocumented?) request to replace the volume attachment isn't successful either:

 curl -i 'http://10.47.52.20:8774/v2/35c70d4fc1414f708a547a9a6ee179ad/servers/6ae98f88-e706-44de-91f3-8756f9ba7ef6/os-volume_attachments/f5e5e5f6-61ce-4601-a7c5-c09cf2392425' -X PUT -H "X-Auth-Project-Id: Demo" -H "User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: xxx" -d '{"volumeAttachment": {"volumeId": "401c6474-5d41-4bb7-a461-b20f64014003"}}'
HTTP/1.1 202 Accepted
Content-Type: text/html; charset=UTF-8
Content-Length: 0

in spite of the empty response not reporting any error. This request also doesn't work for non-boot volumes.

[Eli Qiao (taget-9)]

checked the api code, if you are supported to detach a root volume , API will raise HTTPForbidden.

since you request to detach root volume, I suggest that we add a configure item to indicate if user/admin can detach a root volume, will that make sense to you ?

[Schad (ubuntu-20-schad)]

Yes this would be ok for me.

I would prefer not to habe a new configuration item. What would be the default?

I don't think that root volume detachment should be avoided. This only makes sense for ephemeral volume that would probably be deleted in this case. Would it be possible to reject detaching if the volume is an (1) ephemeral (2) root volume?

[Robert Collins (lifeless)]

So, I don't understand something here. The vast majority of guests will break if you detach their root - only guests that deliberately load all resources into ram and then unmount / won't. All Windows guests will break, and all regular end-user unix style OS's too.

I can see how you'd make a particular image that will survive, but its exception - and you could similarly create two volumes, one tiny chain loader, and one with the stuff you want to really boot off (and then detach later) to get the same effect even when detaching the root device is prohibited.

Based on my understanding, I'm going to mark this incomplete (and then reject it when it times out): I think we should reject it, since:
 - the current behaviour is vastly preferrable to most of our users
 - it appears that there is a trivial workaround for folk that do need to replace their boot material live (see above)

Please do follow up with more details about your use case if I've gotten something wrong. Thanks.

[Schad (ubuntu-20-schad)]

The use case is to remove the root volume of an instance while this being powered off. A different volume will then be attached. This keeps the whole configuration (especially MAC addresses of network ports) while changing the software.

There was never the intention to replace boot material live.

So please, could it be an option to check if
1. the instance is not running/ not live and
2. the root volume is not ephemeral
and in this case allow for root volume detachment.

[Joe Gordon (jogo)]

"The use case is to remove the root volume of an instance while this being powered off. A different volume will then be attached. This keeps the whole configuration (especially MAC addresses of network ports) while changing the software."

This isn't a use case we are trying to support, this goes against the 'cloud' model etc.

[lindis (t-openstack)]

I do believe the use case is valid; especiall when using a volume created from a snapshot. If the volume is using a persistence-net file on linux, the system will not boot up. Although, this may go against some ideas of "cloud," it is not valid to blanket deny a request that has valid production use cases, especially for Fortune 100 companies who are transitioning from legacy hypervisor models to an OpenStack model. This allows systems to have a valid roll back option that satisfies regulatory requirements for large audited companies. Albeit, the change would add value to OpenStacks adoption with larger insitutions looking to get away from vendor proproietary technologies.

[lindis (t-openstack)]

There is a curious response to be made, if this goes against the "cloud" model, why do we have cinder backup and cinder snapshot with OpenStack? Inhereintly, having these functions should alone justify the need to be able to remove a root volume while the system is powered off; otherwise we should just cancel support for Cinder Snapshot and Cinder Backup.

"The use case is to remove the root volume of an instance while this being powered off. A different volume will then be attached. This keeps the whole configuration (especially MAC addresses of network ports) while changing the software."

This isn't a use case we are trying to support, this goes against the 'cloud' model etc.

[Vitalii (vb-d)]

I agree that reasons for not supporting root replacement are completely made up and can not withstand any critic.
You force users to create new instances and delete previous ones, which introduce HUGE overhead and issues with performance !

[Schad (ubuntu-20-schad)]

Thank you for supporting my point. Please, if you want to have root disk replacement back, could you support this bug by saying you are affected?

There are many valid use cases to do that (see above).

[Matthew Monaco (mwtt)]

@Joe Gordon. I can understand "patches welcome," "not a priority," etc. But "against the 'cloud'" model is infuriatingly stupid. There's no technical reason not to support this. The cloud model is unbounded flexibility. Supporting this seems like replacing one conditional sanity check with another; I know libvirt isn't blocking this.

[Schad (ubuntu-20-schad)]

Please also have a look at the code release comment (cited in my first try to address this in a bug report here: https://bugs.launchpad.net/openstack-api-site/+bug/1293695):

"We can either give a warning message, or not allow it. This patch forbids this operation, considering that even in real system, remove root device does not make much sense."

So, in this Intel employee's opinion, allowing root volume detachment didn't make sense. This is why he or she disabled it.

[lindis (t-openstack)]

This inability to remove a root volume from a nova instance while it's off had significant negative implications to my existing openstack deployment and impacts hundreds of applications and thousands of users. It is a large reason why I am currently unable to host critical legacy web/app/db for reasons of not meeting regulatory requirements for rapid restore. The re-provisioning of the system also changes all the UIDs and breaks other management aspects of tools connected to cloud as the nova UID changes. This limitation is disruptive and is likely preventing other deployments from being very successful.

[Fabio Da Soghe (fabiodasoghe)]

This is a total disruptive behaviour for us. Besides what already mentioned above, creating a new VM instance to restore a backup will change the Windows license, forcing our customers to buy another license. Of course this use case cannot be supported in any real world, and honestly I don't understand what type of business such "cloud model" can support.

Of course I'm talking about detaching a root volume while the instance is suspended/turned off.

And, yes, we need to do backups in cloud, because our customers want to be free to delete a file and ask for a (paid) restore.

[Gregor (chef-h)]

Here's another use case: We use the "retype" cinder function to relocate existing volumes to another storage backend. As expected, it only works for detached volumes. But since we cannot detach root volumes even from a shut down instance, we cannot retype root volumes at all. So I'd suggest to either remove the retype function or allow detaching root volumes of shut down instances.

[Yusuf Güngör (yusuf2)]

so there is no valid explanation for not supporting this feature :(