[SDK][CLI][API][OpenAPI] Machine readable OpenStack API spec - time to do a next step?

Christian Rohmann christian.rohmann at inovex.de
Fri Sep 1 13:23:36 UTC 2023


On 31.08.23 16:39, Artem Goncharov wrote:
> Once we have specs for the commands code generators can be updated to 
> consume this data and produce much better code. BTW, I have now also a 
> prototype of the new CLI written with Rust and this is a hypersonic 
> bullet compared to the current OSC. But please do not push me more on 
> that, it is still in a very early stages and depends heavily on the 
> available specs. I can only say that it is now designed in the way 
> that every API call can have a thin CLI coverage just by providing a 
> spec, when additional logic is desired - surely will require human 
> implementation.
> Code generators in the pipe: OSC, AnsibleModules, RustSDK 
> (sync/async), RustCLI. Next thing that are on the radar: gopher cloud, 
> terraform modules, async python sdk, JS SDK(?)
>
> If all of that gets executed properly and with some community traction 
> we can all have following things covered:
>
> - improve standardisation of OpenStack internals and externals: glance 
> and nova (at least those 2) are already using jsonschema internally in 
> different areas to describe requests/responses. Why not to make this 
> standard reaching the service consumers?
> - getting rid of api-ref work by updating our sphinx machinery to 
> consume our customised specs and produce nice docs matching the reality
> - sharing specs between teams to improve interface (not like currently 
> we need to read the api-ref with tons of bugs plus source code to 
> understand how to cover new feature in service X). Maybe even a 
> central repo with the specs per release.
> - there are plenty of code generators and server bindings for OpenAPI 
> specs so that we can potentially align frameworks used by different 
> teams to maintain less
> - less work for all of us who needs services talking to each other 
> (not immediately right now, but once the code is switched on consuming 
> specs)
> - request verification already on the client side not waiting for the 
> response
> - finally show something to customers often annoying asking “where are 
> your openapi specs” (no offence here ;-))?
>
> I know it is a long message. But I am pretty excited with the progress 
> and would like to hear community opinions. For the more detailed 
> discussion consider this as a pre-announcement of the topic for PTG in 
> sdk/cli slots.


You have every reason to be excited - this sounds simply awesome!

I am a huge fan of OpenStackSDK and Gophercloud and the progress of 
aligning the contact surface to OpenStack APIs. Moving away from all the 
individual clients and different usage patterns ...
But your new goals bring things to a whole new level! This is how a 
modern API landscape should look like! Validated and standardized 
schemas + code auto-generation for all sorts of API clients!


Let's go!


Christian





More information about the openstack-discuss mailing list