Ups, used wrong button and replied to Sean only, reposting my replies here directly

Hey,

thanks for feedback

see comments inline

...

...

=== openstack-openapi https://gtema.github.io/openstack-openapi/

This repo hosts rendered specs and provides analogue to the os-api-ref Sphinx extension that renders them into the html (what you see under the link is a mix of Swagger and os-api-ref style). I was not really effectively working on that rendering lately, the repo right now is more or less a storage for the specs themselves with a first sketch of sphinx extension of rendering and basic OpenAPI flavoring doc.

i personally object to haveing a offical repo to define the open api scemas for offial projcet that scope of the relevent repo.

i.e. i do not agree that we shoudl have openapi defintion for the nova api ourside of the nova repo or a repo that is not a deliverable of the comptue project.

stephen has proposed a spec to add openapi support to nova directly https://review.opendev.org/c/openstack/nova-specs/+/909448

I was referring to that spec in the header of my email

...

what i really dont wnat to see is going forward an api change to nova woudl also requrie the oepnapi schema be updated by submiting a patch to a speratre repo. so im fine with haveing schemas in the nova repo but im not ok with having a https://opendev.org/openstack/openstack-openapi/ repo

Please do not mix jsonschemas in services and the resulting OpenAPI spec file.

Anyway, I was thinking about such approach also. Issue, but not really critical for me, is that having schemas in various repos will make it harder for the user to actually grep them, unless we build a single page with links to all specs.

In addition to that with the spec generated by a different tool we are going to have some workflow issue: schema is an artifact of a build and need to be hosted somewhere permanently. You would be having problem in having an API affecting change which during merge generates spec and this spec being submitted into the repo as well. Forcing devs to manually invoke the generator and include the spec into the change is definitely a very strong no-go for me, this will be a disaster. Pushing rendered specs to some artifacts server is necessary.

In any case what is required is to have a sphinx-extension that allows us to generate docs for the schema and this repo is primarily is exactly about that (I have no issue renaming it to better indicate that fact). Just as a matter of temporary demonstration it also hosts the rendered specs.

# My "ideal" workflow would look like that:

- service developer creates change like above that changes the API

- Zuul job generates OpenAPI spec for the service respecting the change and publishes it together with job artifacts (just like docs right now)

- Once a change is merged the OpenAPI spec artifact is published as a deliverable (just like doc job publishes built docs). Maybe the api-ref job can be modified to publish openapi spec and rendered HTML together

- [from here absolutely speculatively]

- another job kicks in and automatically proposes changes to projects that consume this OpenAPI spec (like a change toward the SDK is automatically opened that applies corresponding change)

- dependent project developers review this automatic change and merge/modify it as necessary

...

...

=== openstack-rs https://gtema.github.io/openstack/

This is a Rust monorepo project with few items: - SDK for OpenStack out of the rendered OpenAPI specs - experimental CLI following very different approach compared to the

python- openstackclient. It is compiled into single binary (what helps those not willing to pull whole python with all deps and the insanity we experience lately or those who build docker containers with only OSC inside to bypass the mentioned hell) and purely auto-generated from the specs

- [future] openstack-tui (similar to k9s for Kubernetes)

i was actully playing with rust and pyo3 to try and generate rust data types form the jsonscheam defintion of novas oslo versioend objects https://github.com/SeanMooney/nova-oxide thats mainly to paly with rust and rust<>python interaction in partarlary.

i was toying with the idea of writing a deamon that coudl comuncitate with nova comonets over the rpc bus effectivly a rust implemetiaon of a nova-comptue agent as way to learn rust. basically nova-comput ewould need effectivly a rewrite to remove our use of eventlet anyway so i was toying with the idea of if we are rewriting should we rewtien in something other then python.

have you considerd using something like pyo3 to provide python binding around a rust inmpelmation of the sdk to support both lanageues form a singel codeabse. https://pyo3.rs/v0.20.3/

Yes, it is clearly possible and I am poking with idea of integrating generated code into the openstacksdk (at least in some parts like auth caching).

I really think of having a new openstacksdk2 that is either also generated from specs or is under the hood uses the rust sdk. Changing the current OpenStackSDK would require huge breaking changes, so this is not in the scope right now.

...

...

Here it is all really oriented only on the user facing tooling. I am very convinced in this project and will continue working on it independent on the outcome.

Any objections/ideas/comments?

yep see above. mainly just decopleing the schmas form the implemation. if we keep the schemas with the python code in the same repo or in a lib repo provded by each service project

I do not get the point here really.

- Ideally every service is extending schemas already present in the code and adds descriptions directly into the code. - from schemas in the service code we are able to generate OpenAPI - the OpenAPI spec can be used to render API docs of the service - OpenAPI specs can be used to generate client facing (and possibly also server bindings) tooling (sdk, cli, etc)