| 2015-07-17 13:21:55 |
raphael.glon |
bug |
|
|
added bug |
| 2015-07-17 13:24:53 |
raphael.glon |
description |
Reproduced on juno version (actually tested on a fork from 2014.2.3, sorry in advance if invalid but i think the legacy version is also concerned by it)
not tested on younger versions, but looking at the code they seem impacted too
For Rbd imagebackend only, when unrescuing an instance the disk.rescue file is actually not deleted on remote storage (only the rbd session is destroyed)
Consequence: when rescuing instance once again, it simply ignores the new rescue image and takes the old _disk.rescue image
Reproduce:
1. nova rescue instance
(take care that you are booted to the vda rescue disk -> when rescuing an instance from the same image it was spawned from (case by default), since fs uuid is the same according to fsstab of the template (entry UUID=) you can actually boot from the image you are actually trying to rescue, but this is another matter that concerns template building)
edit rescue image disk
2. nova unrescue instance
3. nova rescue instance -> you get back the disk.rescue spawned in 1
if confirmed, fix coming soon
Concerning fix several possibilities:
- nova.virt.libvirt.driver :LibvirtDriver-> unrescue method, not deleting the correct files
or
- nova.virt.libvirt.imagebackend:Rbd -> erase disk.rescue in create image method if already existing
Rebuild not concerned by issue, delete instance correctly deletes files on remote storage |
Reproduced on juno version (actually tested on a fork from 2014.2.3, sorry in advance if invalid but i think the legacy version is also concerned by it)
not tested on younger versions, but looking at the code they seem impacted too
For Rbd imagebackend only, when unrescuing an instance the disk.rescue file is actually not deleted on remote storage (only the rbd session is destroyed)
Consequence: when rescuing instance once again, it simply ignores the new rescue image and takes the old _disk.rescue image
Reproduce:
1. nova rescue instance
(take care that you are booted to the vda rescue disk -> when rescuing an instance from the same image it was spawned from (case by default), since fs uuid is the same, according to your image fstab (if entry UUID=) you can actually boot from the image you are actually trying to rescue, but this is another matter that concerns template building)
edit rescue image disk
2. nova unrescue instance
3. nova rescue instance -> you get back the disk.rescue spawned in 1
if confirmed, fix coming soon
Concerning fix several possibilities:
- nova.virt.libvirt.driver :LibvirtDriver-> unrescue method, not deleting the correct files
or
- nova.virt.libvirt.imagebackend:Rbd -> erase disk.rescue in create image method if already existing
Rebuild not concerned by issue, delete instance correctly deletes files on remote storage |
|
| 2015-07-17 13:40:29 |
raphael.glon |
description |
Reproduced on juno version (actually tested on a fork from 2014.2.3, sorry in advance if invalid but i think the legacy version is also concerned by it)
not tested on younger versions, but looking at the code they seem impacted too
For Rbd imagebackend only, when unrescuing an instance the disk.rescue file is actually not deleted on remote storage (only the rbd session is destroyed)
Consequence: when rescuing instance once again, it simply ignores the new rescue image and takes the old _disk.rescue image
Reproduce:
1. nova rescue instance
(take care that you are booted to the vda rescue disk -> when rescuing an instance from the same image it was spawned from (case by default), since fs uuid is the same, according to your image fstab (if entry UUID=) you can actually boot from the image you are actually trying to rescue, but this is another matter that concerns template building)
edit rescue image disk
2. nova unrescue instance
3. nova rescue instance -> you get back the disk.rescue spawned in 1
if confirmed, fix coming soon
Concerning fix several possibilities:
- nova.virt.libvirt.driver :LibvirtDriver-> unrescue method, not deleting the correct files
or
- nova.virt.libvirt.imagebackend:Rbd -> erase disk.rescue in create image method if already existing
Rebuild not concerned by issue, delete instance correctly deletes files on remote storage |
Reproduced on juno version (actually tested on a fork from 2014.2.3, sorry in advance if invalid but i think the legacy version is also concerned by it)
not tested on younger versions, but looking at the code they seem impacted too
For Rbd imagebackend only, when unrescuing an instance the disk.rescue file is actually not deleted on remote storage (only the rbd session is destroyed)
Consequence: when rescuing instance once again, it simply ignores the new rescue image and takes the old _disk.rescue image
Reproduce:
1. nova rescue instance
(take care that you are booted to the vda rescue disk -> when rescuing an instance from the same image it was spawned from (case by default), since fs uuid is the same, according to your image fstab (if entry UUID=) you can actually boot from the image you are actually trying to rescue, but this is another matter that concerns template building -> see https://bugs.launchpad.net/nova/+bug/1460536)
edit rescue image disk
2. nova unrescue instance
3. nova rescue instance -> you get back the disk.rescue spawned in 1
if confirmed, fix coming soon
Concerning fix several possibilities:
- nova.virt.libvirt.driver :LibvirtDriver-> unrescue method, not deleting the correct files
or
- nova.virt.libvirt.imagebackend:Rbd -> erase disk.rescue in create image method if already existing
Rebuild not concerned by issue, delete instance correctly deletes files on remote storage |
|
| 2015-07-17 15:34:03 |
OpenStack Infra |
nova: status |
New |
In Progress |
|
| 2015-07-17 15:34:03 |
OpenStack Infra |
nova: assignee |
|
raphael.glon (raphael-glon) |
|
| 2015-07-23 13:15:35 |
Jean-Daniel Bonnetot |
bug |
|
|
added subscriber Jean-Daniel Bonnetot |
| 2016-03-07 12:33:02 |
Davanum Srinivas (DIMS) |
nova: assignee |
raphael.glon (raphael-glon) |
|
|
| 2016-03-07 12:33:05 |
Davanum Srinivas (DIMS) |
nova: status |
In Progress |
Confirmed |
|
| 2016-05-10 15:25:31 |
Bartek Żurawski |
nova: assignee |
|
Bartek Żurawski (bartekzurawski1) |
|
| 2016-05-11 09:31:30 |
OpenStack Infra |
nova: status |
Confirmed |
In Progress |
|
| 2016-05-18 21:12:34 |
Diana Clarke |
bug |
|
|
added subscriber Diana Clarke |
| 2016-07-01 15:02:23 |
melanie witt |
tags |
|
ceph |
|
| 2016-10-12 16:04:10 |
OpenStack Infra |
nova: assignee |
Bartek Żurawski (bartekzurawski1) |
melanie witt (melwitt) |
|
| 2016-10-12 22:21:51 |
OpenStack Infra |
nova: status |
In Progress |
Fix Released |
|
| 2016-10-14 18:52:26 |
Matt Riedemann |
nova: importance |
Undecided |
Medium |
|
| 2016-10-14 18:52:30 |
Matt Riedemann |
nominated for series |
|
nova/newton |
|
| 2016-10-14 18:52:30 |
Matt Riedemann |
bug task added |
|
nova/newton |
|
| 2016-10-14 18:58:06 |
Matt Riedemann |
nova/newton: assignee |
|
Lee Yarwood (lyarwood) |
|
| 2016-10-14 18:58:10 |
Matt Riedemann |
nova/newton: importance |
Undecided |
Medium |
|
| 2016-10-14 18:58:13 |
Matt Riedemann |
nova/newton: status |
New |
In Progress |
|
| 2016-10-23 09:10:39 |
OpenStack Infra |
nova/newton: status |
In Progress |
Fix Committed |
|
