[all][TC] OpenStack Client (OSC) vs python-*clients

Brian Rosmaita rosmaita.fossdev at gmail.com
Thu Aug 13 22:45:08 UTC 2020


On 8/13/20 1:03 PM, Artom Lifshitz wrote:
> On Thu, Aug 13, 2020 at 12:45 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
>>
>> On 2020-08-13 17:27:16 +0100 (+0100), Erno Kuvaja wrote:
>> [...]
>>> My question at this point is, do we (as a community) have enough
>>> bodies dedicated to OSSDK _and_ OSC to make this sustainable? I'm
>>> being sincere here as I have not been part of the development of
>>> either of those projects. But if my assumption above is correct, I
>>> think we should talk about these things with their real names
>>> rather than trying to mask this being just OSC vs python-*client
>>> CLI thing.
>>
>> Hopefully this doesn't come across as a glib response, but if people
>> didn't have to maintain multiple CLIs and SDKs then maybe they would
>> have enough time to collaborate on a universal CLI/SDK pair instead.
> 
> Agreed - but historically that's not what happened, so the question
> now is how to improve the situation. My understanding is that osc is
> effectively dead, except as a shell around the sdk, since that's where
> the future lies. So in my mind, efforts should be concentrated on two
> fronts:
> 
> 1. Continue converting osc to use the sdk
> 2. Catch up the SDK

My understanding is that the SDK is supposed to be an opinionated entry 
point to the APIs?  Or am I thinking of some other project?

I'm bringing this up because people say they want a single unified CLI, 
but when I've pushed operators about this, they want a CLI in Victoria 
that implements all the admin operations exposed by the Victorian-era 
APIs.  A CLI built on an opinionated SDK is not going to do that.

I could use some clarification on the goal and strategy here.  If it's 
to provide a unified opinionated CLI, then I don't see how that helps us 
to eventually eliminate the project-specific CLIs.

And if it's to provide one CLI that rules them all, the individual 
projects (well, Cinder, anyway) can't stop adding functionality to 
cinderclient CLI until the openstackclient CLI has feature parity.  At 
least now, you can use one CLI to do all cinder-related stuff.  If we 
stop cinderclient CLI development, then you'll need to use 
openstackclient for some things (old features + the latest features) and 
the cinderclient for all the in between features, which doesn't seem 
like progress to me.

Thus it would be helpful to have some clarification about the nature of 
the proposal we're discussing.

> 
> This is a bit of a chicken and egg problem, because any gaps in sdk
> mean you can't convert osc to use those missing bits, but ideally any
> patches to osc that aren't sdk conversions would get blocked (though I
> have obviously absolutely no say in the matter, this is just wishful
> thinking). The project teams can work on 2 for their project (so like
> I've been slowly doing for Nova), the osc team can work on 1. >
> 
> 
>> --
>> Jeremy Stanley
> 
> 




More information about the openstack-discuss mailing list