Nikola, just clearing out some old ML threads, but thought you might
want to respond to this one...
Best,
-jay
On 05/11/2015 06:38 AM, Feodor Tersin wrote:
Hi.
Since that bdm v2 was introduced for Havana, it requires a caller to
specify bdm for an image together with imageRef to boot an instance in a
case of using bdm v2 to attach additional volumes.
{"server": {"imageRef": "xxx",
"block_device_mapping_v2": [
{"uuid": "xxx",
"source_type": "image",
"destination_type": "local",
"boot_index": 0,
},
<other_mappings>
],
...}}
If we specify imageRef or the bdm record only, the launch will be failed.
Novaclient does it [1] for shell invokes like
nova boot --image xxx --block_device <other mappings> ...
, but does nothing for client API calls.
Such feature of usage is unclear. I've not found any documentation for
the usage. Wiki [2] doesn't mention this feature, but refers to a
deleted API sample [3]. Before deleting [4] that sample didn't consider
the feature, so it was wrong.
As a result the need to specify an image in two arguments seems a
temprary workaround for some problems. And whole bdm v2 conception looks
not well designed, not finished.
The question is: is this feature correct? Shall we specify an image
twice for the long term? Otherwise which manner should be established
finally: by imageRef or by an bdm record?
ps. There are a review [5] and a linked bug [6] which require
clarification of this question.
[1]
https://github.com/openstack/python-novaclient/commit/6a85c954c53f868251413db51cc1d9616acd4d02#diff-4812fe2b8b37d18cf9498f9fbbab17beR125
[2]
https://wiki.openstack.org/wiki/BlockDeviceConfig#API_data_model_and_backwards_compat_issues
[3]
https://github.com/openstack/nova/tree/master/doc/api_samples/os-block-device-mapping-v2-boot
[4]
https://github.com/openstack/nova/blob/2f32996c3e5625245a4d0588ab32880d41400b9e/doc/api_samples/os-block-device-mapping-v2-boot/server-post-req.json
[5] https://review.openstack.org/#/c/171984/
[6] https://bugs.launchpad.net/nova/+bug/1441990
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
