Booting from image in ceph is considered to booting from volume

[Bing Li]

Openstack Mitaka
glance backend: ceph
nova backend: kvm+ceph
cinder backend: ceph

Steps to reproduce
==================
1.create an instance booting from image with flavor m1.small;
2.nova resize $instance_id m1.tiny;

Actual result
=============
instance resize successfully, but instance's root disk does not change

Expected result
===============
nova-api should raise a ResizeError exception.

booted_from_volume = self._is_booted_from_volume(instance, disk_info_text)
if (root_down and not booted_from_volume) or ephemeral_down:
 reason = _("Unable to resize disk down.")
 raise exception.InstanceFaultRollback(
  exception.ResizeError(reason=reason))

I think the function "_is_booted_from_volume" is wrong:
@staticmethod
def _is_booted_from_volume(instance, disk_mapping):
 return ((not bool(instance.get('image_ref')))
   or 'disk' not in disk_mapping)

[Tao Li (eric-litao)]

I think this judge is not consistent in spawning. In spawning phase, driver consider it as not boot from volume because of the different parameters for _is_booted_from_volume function. so we should modify the same input same to the spawning'w judge.

[Lee Yarwood (lyarwood)]

_is_booted_from_volume should always return False for instances booting from an image, even when the image is using the rbd imagebackend. As Mitaka is now only security-supported I had a quick look to see if this would reproduce against master and everything WORKSFORME :

$ pwd
/opt/stack/nova
$ git rev-parse HEAD
d768bfa2c2fb774154a5268f58b28537f7b39f69

$ nova flavor-list
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True |
[..]
| d1 | ds512M | 512 | 5 | 0 | | 1 | 1.0 | True |
[..]
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
$ nova boot --image cirros-raw --flavor 1 test-resize
$ nova resize test-resize d1
$ sudo rbd -p vms ls -l
NAME SIZE PARENT FMT PROT LOCK
67e542f2-6a21-4363-818b-4ed58be529dd_disk 5120M images/ec027d6b-f677-40fd-b3c9-f0d30ef460de@snap 2
67e542f2-6a21-4363-818b-4ed58be529dd_disk@nova-resize 1024M images/ec027d6b-f677-40fd-b3c9-f0d30ef460de@snap 2
$ nova resize-confirm test-resize
$ sudo rbd -p vms ls -l
NAME SIZE PARENT FMT PROT LOCK
67e542f2-6a21-4363-818b-4ed58be529dd_disk 5120M images/ec027d6b-f677-40fd-b3c9-f0d30ef460de@snap 2

I can't see anything obvious going back to Mitaka regarding rbd imagebackend resizes. If this still reproduces for you on Mitaka, Newton or master can you provide an example n-cpu.log for review?

[Lee Yarwood (lyarwood)]

My apologies, I assumed we were talking about resizing up and I had to re-read your description to see that this was actually about resizing down. The following review moved _is_booted_from_volume to use block_device_info and appears to correct this on master, I'll look into a stable/newton backport shortly :

libvirt: Improve _is_booted_from_volume implementation
https://review.openstack.org/#/c/382024/

Again using my local env this now WORKSFORME when I attempt to resize down :

$ sudo rbd -p vms ls -l
NAME SIZE PARENT FMT PROT LOCK
67e542f2-6a21-4363-818b-4ed58be529dd_disk 5120M images/ec027d6b-f677-40fd-b3c9-f0d30ef460de@snap 2
$ nova resize test-resize 1
$ grep ResizeError ../logs/n-cpu.log
2017-01-04 08:13:24.779 TRACE oslo_messaging.rpc.server ResizeError: Resize error: Unable to resize disk down.
$ sudo rbd -p vms ls -l
NAME SIZE PARENT FMT PROT LOCK
67e542f2-6a21-4363-818b-4ed58be529dd_disk 5120M images/ec027d6b-f677-40fd-b3c9-f0d30ef460de@snap 2