[Openstack-operators] [Openstack-sigs] [openstack-dev] [goals][tc][ptl][uc] starting goal selection for T series
doug at doughellmann.com
Thu Sep 27 14:06:06 UTC 2018
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 . 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
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.  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
>> 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?
More information about the OpenStack-operators