[openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series

Fox, Kevin M Kevin.Fox at pnnl.gov
Thu Sep 27 19:33:09 UTC 2018

If the project plugins were maintained by the OSC project still, maybe there would be incentive for the various other projects to join the OSC project, scaling things up?

From: Matt Riedemann [mriedemos at gmail.com]
Sent: Thursday, September 27, 2018 12:12 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-sigs] [goals][tc][ptl][uc] starting goal selection for T series

On 9/27/2018 10:13 AM, Dean Troyer wrote:
> On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann<doug at doughellmann.com>  wrote:
>> Monty Taylor<mordred at inaugust.com>  writes:
>>> Main difference is making sure these new deconstructed plugin teams
>>> understand the client support lifecycle - which is that we don't drop
>>> support for old versions of services in OSC (or SDK). It's a shift from
>>> the support lifecycle and POV of python-*client, but it's important and
>>> we just need to all be on the same page.
>> That sounds like a reason to keep the governance of the libraries under
>> the client tool project.
> Hmmm... I think that may address a big chunk of my reservations about
> being able to maintain consistency and user experience in a fully
> split-OSC world.
> dt

My biggest worry with splitting everything out into plugins with new
core teams, even with python-openstackclient-core as a superset, is that
those core teams will all start approving things that don't fit with the
overall guidelines of how OSC commands should be written. I've had to go
to the "Dean well" several times when reviewing osc-placement commands.

But the python-openstackclient-core team probably isn't going to scale
to fit the need of all of these gaps that need closing from the various
teams, either. So how does that get fixed? I've told Dean and Steve
before that if they want me to review / ack something compute-specific
in OSC that they can call on me, like a liaison. Maybe that's all we
need to start? Because I've definitely disagreed with compute CLI
changes in OSC that have a +2 from the core team because of a lack of
understanding from both the contributor and the reviewers about what the
compute API actually does, or how a microversion behaves. Or maybe we
just do some kind of subteam thing where OSC core doesn't look at a
change until the subteam has +1ed it. We have a similar concept in nova
with virt driver subteams.




OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list