[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
details.
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
features.
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
[2]
http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/
[3] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
--
Thanks,
Matt
More information about the openstack-discuss
mailing list