Open Stack

On Thu, 2023-08-31 at 18:36 +0200, Artem Goncharov wrote:
> > 
> > Just an fyi we have jsonschema schmas stored in python dicts for every
> > api in nova
> > https://github.com/openstack/nova/blob/4490c8bc8461a56a96cdaa08020c9e25ebe8f087/nova/api/openstack/compute/schemas/migrate_server.py#L38-L74
> > 
> > we use them in our api tests with eh API scamples which are use both
> > as test and to generate docs
> > https://github.com/openstack/nova/tree/master/doc/api_samples/server-migrations
> > 
> > every time we make an api change we add an api sample and add a secma
> > for that micorversion.
> > 
> > These schemas are also use in the api to validate the requests
> > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrate_server.py#L84-L90
> > 
> > so a lot of the data (boht on the spec  side an confromance side)
> > exits but not in a form that is directly  usabel to export openapi
> > formated documents.
> 
> 
> Thanks Sean, I know that and because of that I mentioned that nova is already using jsonschema. That is more or less
> exactly the point that I want to have a discussion on making this standard by the projects and do this generally with
> the openapi spec instead of bunch of unconnected schemas so that our own lives become hopefully easier.
ya i wanted to highlight that for you and others to see how they can and are currently used.
if we were to standatise this acroos services what i would want to see is the exesitign schemas ported to openapi schema
files which we would then import and uses for our validation.

that is a non trivaial amount of work but a the end of the process we woudl have a set of schma files that could be used
to generate client.

we coudld also add a midelware to oslo mideelware that would optionally be able to enumarate the schemas and server them
form the rest api if loaded.

im not against proting to a well know standard provided we do not loose any fo the test coverage we or validation
capablities we have today as a result.

in nova the schmas benifit us today by narrowing the domain of check we need to preform in the python code directly
i.e. we know if you get to the live_migrate handeler in the nova api that the body is syntacticaly valid
due to the schema vlaidation and that you have permissiosn to perform the operators due to the keystoen auth and policy
checks that have already been done.

that means we only need to validate the semantic i.e. does the instance you asked us to migrate exist? is it in a
migratble state ectra. the schemas get rid of a lot of boilerplate in that regard so i think it would be useful for
other too. and if other project were to add schmea validation today it would make sense ot align to a standard rather
then inventing there own or copyting hte nova code. the nova code works but its kindof our own thign even if it is
jasonschma based so it requires more knowledge to extend and uses then following a standard.

>