[forum][sdk][nova] Closing compute API feature gaps in the openstack CLI - recap

Matt Riedemann mriedemos at gmail.com
Thu May 2 16:11:02 UTC 2019

I wanted to give a quick recap of this Forum session for those that 
couldn't attend and also find owners. Please reply to this thread if 
you'd like to sign up for any specific item. The etherpad [1] has the 

To restate the goal: "Identify the major issues and functional gaps (up 
through Mitaka 2.25) and prioritize which to work on and what the 
commands should do."

We spent the majority of the time talking about existing issues with 
compute API functionality in openstack CLI, primarily boot-from-volume, 
live migration and lack of evacuate support (evacuate as in rebuild on a 
new target host because the source host is dead, not drain a host with 
live migrations [2]).

We then talked through some of the microversion gaps and picked a few to 
focus on.

Based on that, the agreements and priorities are:

**High Priority**

1. Make the boot-from-volume experience better by:

a) Support type=image for the --block-device-mapping option.

b) Add a --boot-from-volume option which will translate to a root 
--block-device-mapping using the provided --image value (nova will 
create the root volume under the covers).

Owner: TBD (on either)

2. Fix the "openstack server migrate" command

We're going to deprecate the --live option and add a new 
--live-migration option and a --host option. The --host option can be 
used for requesting a target host for cold migration (omit the 
--live/--live-migration option for that). Then in a major release we'll 
drop the --live option and intentionally not add a --force option (since 
we don't want to support forcing a target host and bypassing the scheduler).

Owner: TBD (I would split the 2.56 cold migration --host support from 
the new --live-migration option review-wise)

**Medium Priority**

Start modeling migration resources in the openstack CLI, specifically 
for microversions 2.22-2.24, but note that the GET /os-migrations API is 
available since 2.1 (so that's probably easiest to add first). The idea 
is to have a new command resource like:

openstack compute migration (list|delete|set) [--server <server_id>]

Owner: TBD (again this is a series of changes)

**Low Priority**

Closing other feature gaps can be done on an as-needed basis as we've 
been doing today. Sean Mooney is working on adding evacuate support, and 
there are patches in flight (see [3]) for other microversion-specific 

I would like to figure out how to highlight these to the OSC core team 
on a more regular basis, but we didn't really talk about that. I've been 
trying to be a type of liaison for these patches and go over them before 
the core team tries to review them to make sure they match the API 
properly and are well documented. Does the OSC core team have any 
suggestions on how I can better socialize what I think is ready for core 
team review?

[1] https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps
[3] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc




More information about the openstack-discuss mailing list