[OSC][PTG] Summary: many things to do!

Monty Taylor mordred at inaugust.com
Fri May 10 20:42:41 UTC 2019



On 5/10/19 4:48 PM, 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:

Well, poo. Sorry I missed it.

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

We landed support for image signing in SDK:

https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/image/image_signer.py

so I don't think it would be an issue to also land support for 
encryption. I'd like to have support for signing so that people using 
SDK could do signing. However, like OSC, SDK doesn't use oslo deps, 
largely for the reason you mention - they're written for server side and 
vastly complicate the client-side story. SDK will not grow a dependency 
on os-brick, even an optional one.

How about if we put the encryption routines in SDK, then expose them to 
the server-side components via SDK?

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

++

FWIW - 
https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_compute.py#L736 
is where we define the similar parameters for server create in SDK. As 
we're making the new OSC params, if we can align naming and usage, that 
would likely lead to future joy - unless we can't, in which case it's fine.


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



More information about the openstack-discuss mailing list