Bug 1199639 - RFE: Add capability to detach root device volume of an instance, when in shutoff state
Summary: RFE: Add capability to detach root device volume of an instance, when in shut...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: unspecified
Hardware: All
OS: All
low
low
Target Milestone: ---
: ---
Assignee: OSP DFG:Compute
QA Contact: OSP DFG:Compute
URL: https://blueprints.launchpad.net/nova...
Whiteboard: upstream_milestone_none upstream_defi...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-06 20:35 UTC by david
Modified: 2023-09-07 18:40 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-12-18 10:15:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-4515 0 None None None 2022-03-13 14:15:06 UTC
Red Hat Knowledge Base (Solution) 4619971 0 None None None 2019-11-28 17:23:15 UTC

Description david 2015-03-06 20:35:02 UTC
Description of problem:


Version-Release number of selected component (if applicable):
There is an inability to remove a “root volume” from a nova instance while it is SHUTDOWN. This causes some problems in recovering a machine, as it requires a system be re-provisioned and booting from the restored volumes. When the re-provisioning occurs, there is a mandatory change in MAC address, this causes some problems for systems (dominantly Red Hat Linux) who reference the MAC address for managing assignment of interfaces after the first boot (the file is /etc/udev/rules.d./70-presistence-net-rules)

Rolling back the change or at least building in a “--force” option for the command for the root device would eliminate the need to provisioning a new server to attach volumes, as well as porting the IP address from the old server to the new server (for those using external load balancing and fixed IPs)

Propose adding: nova volume-detach --force <server> <volume>


How reproducible:

Steps to Reproduce:
1. create nova instance w/ --block_device_mapping where the block device is bootable to vda
2. validate machine works with the bootable volume
3. turn machine off
4. attempt to remove volume

Actual results:
nova volume-detach <serverid> <volumeid>
ERROR (Forbidden): Can't detach root device volume (HTTP 403) (Request-ID: req-57159c1c-5835-4a44-8e41-1b822b92127e)

Expected results:
nova volume-detach <serverid> <volumeid>
volume detached

Additional info:
https://bugs.launchpad.net/nova/+bug/1396965
https://bugs.launchpad.net/nova/+bug/1391196

original bug (fix). I do not believe the intent was to make it FORBIDDEN to remove the root volume while the machine was off. 
https://bugs.launchpad.net/nova/+bug/1279300

Comment 4 David Hill 2016-04-24 20:20:50 UTC
This is a blueprint [1] approved for Newton and making slow progress.

[1] https://blueprints.launchpad.net/nova/+spec/detach-boot-volume

Comment 7 Stephen Gordon 2017-03-14 16:54:52 UTC
Re-targeting to Queens/RHOSP 13 for re-evaluation, unfortunately we do not have scope to work on this during the Pike/RHOSP 12 cycle.

Comment 9 Red Hat Bugzilla Rules Engine 2017-07-24 02:04:12 UTC
This bugzilla has been removed from the release since it has not been triaged, and needs to be reviewed for targeting another release.

Comment 10 Stephen Gordon 2017-08-02 16:32:13 UTC
The upstream work on this was previously abandoned. We understand the desire to enable this use case but have concerns about the amount of assumptions likely to exist in the nova code base that would be impacted by this change (read: likely significant refactoring required).

Given we would like to focus more of our attention on stabilization for Queens/RHOSP 13 we would therefore need to defer any attempts to revive this work until at least Rocky/RHOSP 14.

Comment 14 david 2018-04-23 23:41:15 UTC
I don't use OpenStack anymore; the original bug was a show stopped so moved on from that. No idea what "needinfo" is needed, but I can't contribute to this bug anymore. Long story short, this bug prevented a large deployment from being successful in 2015 (10,000 plus instances), over three years ago. I don't know what else to add. Thank you.

Comment 15 David Hill 2018-05-03 14:26:53 UTC
I'm reopenining this BZ because it was requested by another customer.  If it's too hard to implement, just let us know so we can set expectations accordingly.

Comment 16 Lee Yarwood 2018-05-08 19:56:37 UTC
(In reply to David Hill from comment #15)
> I'm reopenining this BZ because it was requested by another customer.  If
> it's too hard to implement, just let us know so we can set expectations
> accordingly.

While this is awkward we shouldn't close this out for now, at least until #1449607 implements volume backed instance rescue.

Moving to rhos-15.0? for now to move this out of our rhos-14.0 queries.

Comment 17 smooney 2019-04-10 15:46:21 UTC
As per the upstream discussion detaching and ataching root volum can invaldate the placement of
the vm by changing the numa/pining requiremetn or via traits on the image.
http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003178.html
https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR+status:merged)

The ability to detach the root volume is still progressing upstream but has reverted to only supporting shelved
instances.

Comment 18 Lee Yarwood 2019-12-18 10:15:28 UTC
Closing this out as WONTFIX given it hasn't been accepted for 17.0 and the previous upstream work to support this with unshelved instances has been abandoned.


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