Open Stack

On 03/16/2015 03:55 PM, aburluka wrote:
> Hello Nova!
> 
> I'd like to ask community to help me with some unclear things. I'm
> currently working on adding persistent storage support into a parallels
> driver.
> 
> I'm trying to start VM.
> 
> nova boot test-vm --flavor m1.medium --image centos-vm-32 --nic
> net-id=c3f40e33-d535-4217-916b-1450b8cd3987 --block-device
> id=26b7b917-2794-452a-95e5-2efb2ca6e32d,bus=sata,source=volume,bootindex=1
> 
> Got an error:
> ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for
> the instance and image/block device mapping combination is not valid.
> (HTTP 400) (Request-ID: req-454a512c-c9c0-4f01-a4c8-dd0df0c2e052)
> 
> 
> nova/api/openstack/compute/servers.py
> def create(self, req, body)
> Has such "body" arg:
> {u'server':
>     {u'name': u'test-vm',
>      u'imageRef': u'b9349d54-6fd3-4c09-94f5-8d1d5c5ada5c',
>      u'block_device_mapping_v2': [{u'disk_bus': u'sata',
>                                    u'source_type': u'volume',
>                                    u'boot_index': u'1',
>                                    u'uuid':
> u'26b7b917-2794-452a-95e5-2efb2ca6e32d'}],
>      u'flavorRef': u'3',
>      u'max_count': 1,
>      u'min_count': 1,
>      u'networks': [{u'uuid': u'c3f40e33-d535-4217-916b-1450b8cd3987'}],
>      'scheduler_hints': {}
>     }
> }
> 

So the reason you get such an error is because there is no block device
mapping with boot_index 0. This is for somewhat historical reasons -
when the new block device mapping syntax (so v2, see [1]) was
introduced, the idea was to stop special-casing images, and treat them
as just another block device. Still most of the driver code
special-cases the image field, so this block device is not really used
internally, but is checked for in the API when we try to validate the
boot sequence passed.

In order for this to work properly, we added code in the
python-novaclient to add a (somewhat useless) block device entry (see
commit [2]) so that the DB is used consistently and the validation passes.

[1] https://wiki.openstack.org/wiki/BlockDeviceConfig
[2] https://review.openstack.org/#/c/46537/1

> Such block device mapping leads to bad boot indexes list.
> I've tried to watch this argument while executing similiar command with
> kvm hypervisor on Juno RDO and get something like in "body":
> 
> {u'server': {u'name': u'test-vm',
>  u'imageRef': u'78ad3d84-a165-42bb-93c0-a4ad1f1ddefc',
>  u'block_device_mapping_v2': [{u'source_type': u'image',
>                                u'destination_type': u'local',
>                                u'boot_index': 0,
>                                u'delete_on_termination': True,
>                                u'uuid':
> u'78ad3d84-a165-42bb-93c0-a4ad1f1ddefc'},
> 
>                              {u'disk_bus': u'sata',
>                               u'source_type': u'volume',
>                               u'boot_index': u'1',
>                               u'uuid':
> u'57a27723-65a6-472d-a67d-a551d7dc8405'}],
>  u'flavorRef': u'3',
>  u'max_count': 1,
>  u'min_count': 1,
>  'scheduler_hints': {}}}
> 

The telling sign here was that you used RDO to test.

I spent some time looking at this, and the actual problem here is that
there is a line of code removed from the python-novaclient not too long
ago, that is present in the RDO Juno nova client, that actually makes it
work for.

The offending commit that breaks this for you and does not exist in the
RDO-shipped client is:

https://review.openstack.org/#/c/153203/

This basically removes the code that would add an image bdm if there are
other block devices specified. This is indeed a bug in master, but it is
not as simple as reverting the offending commit in the nova-client, as
it was a part of a separate bug fix [3]

Based on that I suspect that point the older (RDO Juno) client at a Nova
that contains the fix for [3] will also exsibit issues

Actually there is (at the time of this writing) still code in the Nova
API that expects and special-cases the case the above commit removes [4]

[3] https://bugs.launchpad.net/nova/+bug/1377958
[4]
https://github.com/openstack/nova/blob/4b1951622e4b7fcee5ef86396620e91b4b5fa1a1/nova/compute/api.py#L733

> Can you answer next questions please:
> 1) Does the first version miss an 'source_type': 'image' arg?
> 2) Where should and image block_device be added to this arg? Does it
> come from novaclient or is it added by some callback or decorator?
> 

I think both questions are answered above. The question that we want to
answer is how to fix it and make sure that it does not regress as easily
in the future.

I have created a bug for this:

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

so we can continue the discussion there.

N.