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/4490c8bc8461a56a96cdaa08020c9e25ebe8f...
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-migrati...
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/mig...
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.