On 9/27/2018 10:13 AM, Dean Troyer wrote:
On Thu, Sep 27, 2018 at 9:10 AM, Doug Hellmann<d...@doughellmann.com> wrote:
Monty Taylor<mord...@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.
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
