Cannot expand root volume by EC2 API

[Feodor Tersin]

AWS provides a scenario to expand volumes of an instance (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-expand-volume.html). It consist of:
1 Stop the instance
2 Create a snapshot of the volume
3 Create a new volume from the snapshot
4 Detach the old volum
5 Attach the new volume using the same device name
6 Start the instance

In Nova this works for non-root devices, but doesn't for a root device.

Now in current version (Juno) since https://review.openstack.org/#/c/75552/ was merged it's not able to detach root volume at all.

$ nova volume-detach inst 02f60d80-47ee-47ed-a795-cb4d05f5103e
ERROR (Forbidden): Can't detach root device volume (HTTP 403) (Request-ID: req-e25134dc-1330-4fe1-9d21-abc274e75a1d)

Before this commit it was able, but it was unable to attach the root volume back.

[Boden R (boden)]

My initial approximation of this issue, is that we should update the changes made under https://review.openstack.org/#/c/75552/ (Don't detach root device volume) to take into account the server state.

That is, if the server (VM) is stopped, then permit the root device detach. If the server is running, then do not permit the root device detach.

Comments on this approach are welcome.

[Boden R (boden)]

@ftersin -- the current implementation of nova's resize supports disk resize as part of the resize operation / workflow. That is; if you resize the server to a flavor which has a larger disk, the resize operation will handle it. IMHO this workflow is much cleaner and more user friendly than a 6 step manual process outlined in the description.

With that in mind it's not clear to me why a 6 step manual process is needed (as per description of this bug) -- is this for AWS parity?

If you feel we need to support the manual root disk resize (e.g. detach root disk + snapshot... + reattach root disk) then to me this is grounds for a blueprint and I would suggest you open a nova blueprint (https://blueprints.launchpad.net/nova) for the requested functionality.

The current nova implementation does not currently handle root disk detach (checked at API layer), nor does it handle root disk attach (compute layer). With a few quick hacks I was able to make this work w/libvirt KVM. However from a user perspective I believe we'd need to think about how this would work / look; something similar to the existing nova resize; or perhaps as an option in resize.

I'm going to close this as will not fix based on my above comments. If you feel this is an incorrect state feel free to re-open.

Thanks

[Feodor Tersin (ftersin)]

@boden
>> is this for AWS parity?
Exactly!

If we claim AWS compatibility, typical AWS scenarios should work fine. This resizing scenario is declared by AWS.
As i understand, the compatibility means, that an end user EC2 script with this scenario should do it's work properly as it is against OpenStack. But now it's not the case.

Moreover there is no other way to resize a root volume by EC2 API.

As you mentioned above we can allow to detach root disk when an instance is stopped. I guess that current prohibition is not the result of deep digging, but the result of easy fixing of https://bugs.launchpad.net/nova/+bug/1279300 (detach boot device volume without warning).

Also for attaching a root device back - as i see, the problem is inspired by usage of block_device.instance_block_mapping to get all current device names. But block_device.instance_block_mapping returns root device even though it isn't attached (and this is used in other case when it's called).

Thus Nova doesn't contain explicit restrictions to reattach a root device. Nova architecture allows this, but certain minor parts of code prevent it. So i reopen the bug. I hope it can be resolved.

[Feodor Tersin (ftersin)]

but how can i reopen it? i don't see statuses other than 'wan't fix' in the combobox

[Boden R (boden)]

Regarding changing the status -- I think you have to be a member of the nova bugs LP group to do that: https://launchpad.net/~nova-bugs

W/R/T the technicals of this request; IMHO this is still grounds for a blueprint. It's unclear to me if all hypervisors would support attaching a root disk and if so if the current constructs would facilitate it. That said I'd rather see this come through as a blueprint to get the nova team on the same page through that process. However that's just my 2 cents.