Open Stack

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

* 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


-- 
Dean Troyer
dtroyer at gmail.com