create vm fail by volume when use diskfilter

Fix proposed to branch: master
Review: https://review.openstack.org/103288

Fix proposed to branch: master
Review: https://review.openstack.org/113161

Change abandoned by warewang (<email address hidden>) on branch: master
Review: https://review.openstack.org/103288

Fix proposed to branch: master
Review: https://review.openstack.org/113508

Change abandoned by warewang (<email address hidden>) on branch: master
Review: https://review.openstack.org/113508

Fix proposed to branch: master
Review: https://review.openstack.org/113757

Change abandoned by warewang (<email address hidden>) on branch: master
Review: https://review.openstack.org/113161

Change abandoned by Sean Dague (<email address hidden>) on branch: master
Review: https://review.openstack.org/113757
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Fix proposed to branch: master
Review: https://review.openstack.org/136284

Change abandoned by Joe Gordon (<email address hidden>) on branch: master
Review: https://review.openstack.org/136284
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

Fix proposed to branch: master
Review: https://review.openstack.org/184982

Hi zhangtralon,

I have added new patch because there was no activity on this bug for long time.
If you are working on this then you can reassign it to yourself.

Hi Abhijeet
    zhangtralon has quitted OpenStack community for some reason.He has Assigned this bug to me.But I reviewed your patch briefly.It looks good.So,I think you can work on it continually.I'll follow it.

Thanks

Fix proposed to branch: master
Review: https://review.openstack.org/189581

This is interesting because if you select an image to create a new volume to boot from, it works
in my case, Micro-Small has a 50GB root disk, the image used is 2.1GB qcow2

e.g.
nova boot --poll --flavor Micro-Small --block-device source=image,id=da3c219e-591d-4939-b930-15807b8d0e48,dest=volume,size=70,shutdown=preserve,bootindex=0 alop-boot-from-vol-cli-larger
Server building... 100% complete
Finished

However, if I were to have created a cinder volume first
cinder create --image-id da3c219e-591d-4939-b930-15807b8d0e48 --display-name vol-boot-test-cli2 55
nova boot --poll --boot-volume 11a02844-59a5-46dc-a78f-e4a1dbb5bf3f --flavor Micro-Small --block-device id=11a02844-59a5-46dc-a78f-e4a1dbb5bf3f,source=volume,shutdown=preserve alop-boot-from-vol-cli-larger
ERROR: Flavor's disk is too small for requested image. (HTTP 400) (Request-ID: req-4ca9fb7a-0632-403e-bc22-0a5a682ae1e2)

@Abel Lopez , Hi,the situation you mentioned above is like this bug:

https://bugs.launchpad.net/nova/+bug/1459491

You can take a look at it if you interested.

This bug is in another situation:

When select host in nova-scheduler with vm booted from volume,it compare the flavor's root_gb (2T)with the host's volume (80G).Then it failed.

If flavor is 2G and host is 80G,it will success,and the host's available volume will be 78G.But the vm is booted from volume,it didn't use host's volume.

Related fix proposed to branch: master
Review: https://review.openstack.org/200870

Related fix proposed to branch: master
Review: https://review.openstack.org/203766

Change abandoned by Feodor Tersin (<email address hidden>) on branch: master
Review: https://review.openstack.org/203766
Reason: This was a preparation step to fix bug #1334974 and bug #1358566. The idea was to call is_volume_backed_instance from nova.scheduler.utils.build_request_spec to set root_gb=0 for volume-backed instances.

But since an object refactoring is doing now under https://blueprints.launchpad.net/nova/+spec/request-spec-object , i prefer to wait the result of it.

Change abandoned by Michael Still (<email address hidden>) on branch: master
Review: https://review.openstack.org/189581
Reason: This patch has been stalled for quite a while, so I am going to abandon it to keep the code review queue sane. Please restore the change when it is ready for review.

Change abandoned by Matt Riedemann (<email address hidden>) on branch: master
Review: https://review.openstack.org/184982
Reason: This looks abandoned now.

Hi Feodor, I have seen your patches [1] and [2] which are in merge conflict for long. Just wanted to confirm if you are still willing to fix this issue or we should takeover this task.

[1] https://review.openstack.org/#/c/200870/
[2] https://review.openstack.org/#/c/203766/

Thanks,

Related fix proposed to branch: master
Review: https://review.openstack.org/270482

Reviewed: https://review.openstack.org/270482
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d6210a4d0cdaf8a71d2516bf44f04789cbe89d0c
Submitter: Jenkins
Branch: master

commit d6210a4d0cdaf8a71d2516bf44f04789cbe89d0c
Author: Tobias Urdin <email address hidden>
Date: Wed Jan 20 21:55:33 2016 +0100

    Move is_volume_backed_instance to compute.utils

    This function is a method of ComputeAPI, so its callers must have an
    instance of the class. This make the usage difficult in modules which
    do not need to call ComputeAPI by other reason.

    Besides this function does not use any of the class members. So there is
    no reason for it to be the class method.

    This patch moves this function to compute.utils because it does not use
    anything of the class members.

    This patch also adds support for the _get_root_bdm and
    is_volume_backed_instance to read from a dictionary instead of an
    Instance object. Because of this we can call is_volume_backed_instance
    from build_request_spec and fix bug #1469179.

    Change-Id: I6d446088faf500ed39a4504794d09d0f86e2bbc3
    Co-Authored-By: Feodor Tersin <email address hidden>
    Co-Authored-By: Ankit Agrawal <email address hidden>
    Related-Bug: #1469179
    Related-Bug: #1334974
    Related-Bug: #1358566

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY

Currently booting from volume using Ceph as a backend. The flavors being used for the instances deployed were originally set to 8gb even though each was boot from volume. Scheduler was refusing to provision an instance due to not having enough usable disk space;

2016-11-04 13:01:17.802 1907 DEBUG nova.scheduler.filters.disk_filter [req-1811111-8323-4c19-ad05-9ee265c2a655 111112f9e7c94971b2d6363327b111af 1111712795c44edcbc8ffcc331a59113 - - -] (comp17, comp17.domain.net) ram:117562 disk:1024 io_ops:0 instances:55 does not have 8192 MB usable disk, it only has 1024.0 MB usable disk. host_passes /openstack/venvs/nova-12.0.15/lib/python2.7/site-packages/nova/scheduler/filters/disk_filter.py:60

CONFIRMED FOR: LIBERTY

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/396310

Change abandoned by Matt Riedemann (<email address hidden>) on branch: stable/liberty
Review: https://review.openstack.org/396310
Reason: liberty is end of life

Liberty is EOL. And this bug has kind of wandered all over the place. I think that if there is an issue that we can repeat in Master we should create a new fresh bug and work from there.