On 8/13/20 1:03 PM, Artom Lifshitz wrote:
On Thu, Aug 13, 2020 at 12:45 PM Jeremy Stanley <fungi@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