[all] [tc] [osc] [glance] [train] [ptls] Legacy client CLI to OSC review 639376

Ben Nemec openstack at nemebean.com
Fri Aug 23 23:30:06 UTC 2019



On 8/23/19 5:47 PM, Eric Fried wrote:
>>> reliance on a central (OSC) team for implementation and reviews.
> <snip>>> Would moving tools like cinder or glance to OSC plugins help solve
> <snip>
>> upside is project teams could move things themselves faster, like they
>> do with their own python-*client projects today. They are also the ones
>> that know better how their API works.
> <snip>
>> The downside of project teams owning their parts of the CLI are losing a
>> unified vision
> <snip>
>> we would have to trust them
> <snip>
>> I would still want Dean
>> overseeing things happening at the component level though, at least
>> until there are more obvious OSC-wide cores, i.e. component core(s)
>> +1/+2 a thing but Dean has final say.
> 
> This is becoming a familiar theme for projects/efforts with touchpoints
> across OpenStack.
> 
> Docs deliverables have been moved into individual projects, and "the
> docs team" is becoming a SIG [1]. But who is the Dean of docs, making
> sure we retain a common structure, style, and voice across all of these
> deliverables?
> 
> SDK is making forays into the "trust component SMEs" arena [2].
> 
> The API-SIG is undergoing a similar existential exercise [3], and it is
> unclear where its deliverables will end up.
> 
> And this issue with OSC is not new.
> 
> All of these have their own nuances, but also quite a bit in common. Can
> we brainstorm ways that might address more than one in a satisfactory
> way? Here's one idea:
> 
> Deliverables live in projects under the governance of their component;
> so for example nova-docs and nova-osc-plugin and nova-sdk-plugin would
> be under nova governance, with core teams managed by nova. But patches
> in those projects require an additional vote of a different flavor (a
> "Rollcall-Vote"?) from the related SIG or core team in order to merge.

I don't dislike the idea, but I think the decentralization of these 
things is at least partially a recognition of the fact that the teams 
have shrunk to the point where they can't be responsible for reviewing 
every doc/sdk/cli change across all of openstack (if they ever could in 
the first place). It may be that the best we can do is have the 
remaining experts in those areas write up guidelines[0] for the project 
contributors to follow and then pull the experts in to review specific 
edge cases and such.

The bad thing is that mistakes in stuff like the cli and sdk can be hard 
to fix once they've been released. I can't tell you how many bugs I ran 
into because scripts were using the old glance image visibility cli opt 
that got changed way back when. But that might just be something we have 
to live with unless I'm wrong about the review capacity of the teams in 
question.

0: Something like 
https://docs.openstack.org/python-openstackclient/stein/contributor/humaninterfaceguide.html 
but maybe even more than that since I think I've seen Dean mention best 
practices that aren't covered in that doc.

> 
> Thoughts?
> 
> efried
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.html#8571
> [2]
> http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.html#8362
> [3]
> http://lists.openstack.org/pipermail/openstack-discuss/2019-August/thread.html#8673
> 



More information about the openstack-discuss mailing list