Open Stack

On Thu, May 2, 2019 at 10:15 AM Matt Riedemann <mriedemos at 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**
>
> 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)

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).

> 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
>
>
>


-- 
Artom Lifshitz
Software Engineer, OpenStack Compute DFG