[forum][sdk][nova] Closing compute API feature gaps in the openstack CLI - recap
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-con... [3] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
On Thu, May 2, 2019 at 10:15 AM Matt Riedemann mriedemos@gmail.com wrote:
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**
- 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)
I can take this. I'll also work on all the device tagging stuff - both tagged attach in 2.49 ([3] L122) and the original tagged boot devices in 2.32 (which I've added to [3] as a quick note).
- 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-con... [3] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc
--
Thanks,
Matt
On 5/2/2019 11:11 AM, Matt Riedemann wrote:
**High Priority**
- 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).
I'm now tracking this item in storyboard and have a WIP patch for (a).
https://storyboard.openstack.org/#!/story/2006302
participants (2)
-
Artom Lifshitz
-
Matt Riedemann