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@gmail.com