Open Stack

On Fri, 2019-05-10 at 11:48 -0500, Dean Troyer wrote:
> OpenStackClient held a session at the Denver PTG and despite not
> having much planned had plenty to talk about.  Some of the highlights
> from the etherpad[0] are:
> 
> * Aretm is working on changing the Image commands to use OpenStackSDK.
> This is the work described in the cycle goal proposal[1] that he is
> planning to do anyway.  I support going ahead with this even without
> an SDK 1.0 release as it lets us remove glanceclient and some of its
> unique dependencies.
> 
> * There was some discussion about image encryption and where the
> client-side bits of that may land.  One option was to put it into
> os-brick; if that is where it winds up OSC will make that an optional
> dependency de to the number of other dependencies that will introduce.
> (ie, OSC currently uses very little of oslo, some of which brings in a
> number of things not otherwise needed client-side).
> 
> * Doug brought up the problems with load times due to scanning the
> entire import path on every invocation.  I found in my notes almost
> exactly 2 years ago where we discussed this same topic.  AS we did
> then, the idea of skipping entry points entirely for commands in the
> OSC repo is the best solution we have found.  This would help some
> common cases but still leave all plugins with slow load times.
> 
> * Nate Johnston asked about supporting bulk create APIs, such as
> Neutron's bulk port create.  After kicking around a couple of options
> the rough consensus is around using a YAML file (or JSON or both?) to
> define the resources to be created and giving it to a new top-level
> 'create' command (yes, verb only, the resource names will be in the
> YAML file).  APIs that allow bulk creates will get a single call with
> the entire list, for other APIs we can loop and feed them one at a
> time.  This would be very similar to using interactive mode and
> feeding in a list of commands, stopping at the first failure.  Note
> that delete commands already take multiple resource identifiers,
> adding the ability to source that list from YAML would be an easy
> addition.
> 
> * OSC4 has been waiting in a feature branch for over 2 years (where
> has that PTL been???).  I recently tried to merge master in to see how
> far off it was, it was enough that I think we should just cherry-pick
> the commites in that branch to master and move forward.  So the
> current plan is to:
>   * do one more release in the 3.x series to clean up outstanding things
>   * switch to OSC4 development, cherry pick in amotoki's existing
> commits[2] (mostly changes to output formatting)
>   * refresh and merge other reviews in the osc4 topic
>   * remove all of the backward-compatibility code in the OSC
> authentication process so OSC will now work like all other pure
> keystoneauth- and sdk-using code.
> 
> 
> Also relevant to OSC but covered in a Nova Forum session[3,4], highlights:
> 
> * boot-from-volume: Support type=image for the --block-device-mapping,
> and Add a --boot-from-volume option which will translate to a root
> --block-device-mapping using the provided --image value
> 
> * server migrate --live: deprecate the --live option and add a new
> --live-migration option and a --host option

Could I suggest we don't bother deprecating the '--live' option in 3.x
and simply rework it for 4.0? This is of course assuming the 4.0
release date is months away and not years, of course. 

> * compute migration: begin exposing this resource in the CLI
> 
> dt
> 
> [0] https://etherpad.openstack.org/p/train-ptg-osc
> [1] https://review.opendev.org/#/c/639376/
> [2] this series starts at https://review.opendev.org/#/c/657907/
> [3] https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps
> [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005783.html
> 
>