--image and --volume shouldn't be required if block-device-mapping is provided

[Mehdi Abaakouk]

Hi,

I'm trying to update shell scripts that use nova/neutron/cinder to use only the 'openstack' cli.

The nova command I try to convert is (note the instance have only mapped block devices ):

nova boot --poll --flavor tiny --block-device source=volume,id=47844285-7c51-4993-995b-468ff7fd2123,dest=volume,shutdown=preserve,bootindex=0 --block-device source=volume,id=a17ead3d-b3a7-4032-9ad7-b1c60eb6a24e,dest=volume,shutdown=preserve,bootindex=1 --nic port-id=d955c492-69e6-426f-b723-e78ae85cd101 --availability-zone nova:foobar my_instance

In:

openstack server create --wait --nic port-id=d955c492-69e6-426f-b723-e78ae85cd101 --availability-zone nova:foobar --flavor tiny --block-device-mapping vda=47844285-7c51-4993-995b-468ff7fd2123 --block-device-mapping=a17ead3d-b3a7-4032-9ad7-b1c60eb6a24e my_instance

I have some issues:
* I cannot provide the 'shutdown=' option
* I cannot set the device type (ie: volume or snapshot)
* I got the following error message: openstack server create: error: one of the arguments --image --volume is required

Only the last one really blocks me.

The code seems doing wrong assumptions here: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/server.py#L419

And perhaps block-device-mapping should be part of the disk options group: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/server.py#L250

Cheers,

[Dean Troyer (dtroyer)]

The server create --block-device-mapping probably does need to be updated, Nova has made some changes around here since this was written. Apparently though you are attempting to boot from a volume? Then --volume is required. What we need to work out is passing in the rest of the options to go with the volume.

[Steve Martinelli (stevemar)]

Automatically unassigning due to inactivity.

[Rui Chen (kiwik-chenrui)]

Hi Mehdi:

You can convert your novaclient command to following osc command, but an issue still exist in current master code, the "vdb" volume can't be attached if the command execute. Fortunately we are discussing about the related scenario in patch https://review.openstack.org/#/c/407111/ , welcome to join us to give the details about your case, thank you.

openstack server create --wait --flavor tiny
--volume 47844285-7c51-4993-995b-468ff7fd2123
--block-device-mapping vdb=a17ead3d-b3a7-4032-9ad7-b1c60eb6a24e
--nic port-id=d955c492-69e6-426f-b723-e78ae85cd101
--availability-zone nova:foobar my_instance

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/407111
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=95c8661f86e74c9d5217869a740da11350f1f0eb
Submitter: Jenkins
Branch: master

commit 95c8661f86e74c9d5217869a740da11350f1f0eb
Author: Nikita Gerasimov <email address hidden>
Date: Mon Dec 5 20:47:40 2016 +0300

    Switch server create to block_device_mapping_v2

    Current compute_client.servers.create() relies on block_device_mapping
    arg which is legacy[1]. "block_device_mapping" format require
    device_name which is leads to hard-coded hack in --volume key handler
    to KVM specific. "block_device_mapping_v2" format is more friendly
    to hypervisiors.
    Support of block_device_mapping_v2 appear in python-novaclient 2.16.0,
    openstackclient require at least 2.29.0

    Makes options --volume and --block-device-mapping work simultaneously.
    Appends --block-device-mapping data even if --volume used.
    After bug 1383338 only --volume was taken when both are used.

    [1]http://docs.openstack.org/developer/nova/block_device_mapping.html

    NOTE(dtroyer): I moved the new test_boot_from_volume() functional
    test to Ie51b1c375c5940856ec76a5770df3c6bd18a3eba to test our
    previous behaviour. The only changes required to support the new
    behaviour should be that the empty_volume is now attached in that test.

    Change-Id: I7bac3d870dd9ca404093142f8bce22a62e49180d
    Closes-Bug: 1647406
    Closes-Bug: 1497845

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/python-openstackclient 3.8.0 release.