Open Stack

Dean Troyer <dtroyer at gmail.com> writes:

> On Wed, Sep 26, 2018 at 3:44 PM, Matt Riedemann <mriedemos at gmail.com> wrote:
>> I started documenting the compute API gaps in OSC last release [1]. It's a
>> big gap and needs a lot of work, even for existing CLIs (the cold/live
>> migration CLIs in OSC are a mess, and you can't even boot from volume where
>> nova creates the volume for you). That's also why I put something into the
>> etherpad about the OSC core team even being able to handle an onslaught of
>> changes for a goal like this.
>
> The OSC core team is very thin, yes, it seems as though companies
> don't like to spend money on client-facing things...I'll be in the
> hall following this thread should anyone want to talk...
>
> The migration commands are a mess, mostly because I got them wrong to
> start with and we have only tried to patch it up, this is one area I
> think we need to wipe clean and fix properly.  Yay! Major version
> release!

I definitely think having details about the gaps would be a prerequisite
for approving a goal, but I wonder if that's something 1 person could
even do alone. Is this an area where a small team is needed?

>> I thought the same, and we talked about this at the Austin summit, but OSC
>> is inconsistent about this (you can live migrate a server but you can't
>> evacuate it - there is no CLI for evacuation). It also came up at the Stein
>> PTG with Dean in the nova room giving us some direction. [2] I believe the
>> summary of that discussion was:
>
>> a) to deal with the core team sprawl, we could move the compute stuff out of
>> python-openstackclient and into an osc-compute plugin (like the
>> osc-placement plugin for the placement service); then we could create a new
>> core team which would have python-openstackclient-core as a superset
>
> This is not my first choice but is not terrible either...

We built cliff to be based on plugins to support this sort of work
distribution, right?

>> b) Dean suggested that we close the compute API gaps in the SDK first, but
>> that could take a long time as well...but it sounded like we could use the
>> SDK for things that existed in the SDK and use novaclient for things that
>> didn't yet exist in the SDK
>
> Yup, this can be done in parallel.  The unit of decision for use sdk
> vs use XXXclient lib is per-API call.  If the client lib can use an
> SDK adapter/session it becomes even better.  I think the priority for
> what to address first should be guided by complete gaps in coverage
> and the need for microversion-driven changes.
>
>> This might be a candidate for one of these multi-release goals that the TC
>> started talking about at the Stein PTG. I could see something like this
>> being a goal for Stein:
>>
>> "Each project owns its own osc-<service_type> plugin for OSC CLIs"
>>
>> That deals with the core team and sprawl issue, especially with stevemar
>> being gone and dtroyer being distracted by shiny x-men bird related things.
>> That also seems relatively manageable for all projects to do in a single
>> release. Having a single-release goal of "close all gaps across all service
>> types" is going to be extremely tough for any older projects that had CLIs
>> before OSC was created (nova/cinder/glance/keystone). For newer projects,
>> like placement, it's not a problem because they never created any other CLI
>> outside of OSC.

Yeah, I agree this work is going to need to be split up. I'm still not
sold on the idea of multi-cycle goals, personally.

> I think the major difficulty here is simply how to migrate users from
> today state to future state in a reasonable manner.  If we could teach
> OSC how to handle the same command being defined in multiple plugins
> properly (hello entrypoints!) it could be much simpler as we could
> start creating the new plugins and switch as the new command
> implementations become available rather than having a hard cutover.
>
> Or maybe the definition of OSC v4 is as above and we just work at it
> until complete and cut over at the end.  Note that the current APIs
> that are in-repo (Compute, Identity, Image, Network, Object, Volume)
> are all implemented using the plugin structure, OSC v4 could start as
> the breaking out of those without command changes (except new
> migration commands!) and then the plugins all re-write and update at
> their own tempo.  Dang, did I just deconstruct my project?

It sure sounds like it. Congratulations!

I like the idea of moving the existing code into libraries, having
python-openstackclient depend on them, and then asking project teams for
more help with them.

> One thing I don't like about that is we just replace N client libs
> with N (or more) plugins now and the number of things a user must
> install doesn't go down.  I would like to hear from anyone who deals
> with installing OSC if that is still a big deal or should I let go of
> that worry?

Don't package managers just deal with this? I can pip/yum/apt install
something and get all of its dependencies, right?

Doug