The v3 schema doesn't seem to have much that's different from the v2 schema, let alone better.
oneOf is only used for io.k8s.apimachinery.pkg.api.resource.Quantity and io.k8s.apimachinery.pkg.util.intstr.IntOrString. The latter already has custom codegen. The former advertises itself as "oneOf": [{ "type": "string" }, { "type": "number" }], similar to IntOrString, but its documentation indicates one should always use the string form anyway, so the current codegen (newtype around String) might actually be preferable.
Hacks like JSONSchemaPropsOrArray are still present, and still need to be treated in the same way.
"allOf" is only used with a single element in each use site, so it's not providing any new info, just associating the field / parameter with its type.
Neither of the two extent "upstream bugs" have been fixed. GVK still references NodeProxyOptions etc that don't exist as definitions. connectCoreV1GetNamespacedPodExec still annotates its command querystring parameter as a single string.
List operations still include watch operation parameters, so they still need to be split apart.
Any other validations that restrict values - "enum", the various "min" and "max", "pattern" etc - are not used anywhere.
The schema is split into ~50 files, two per API group, and they all reference types from each other. This means a) lots of files would need to be downloaded instead of one swagger.json, and b) a large portion of each would be redundant and need to be thrown away. Eg io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta is defined identically in 24 files.
So at this point the only reason to implement support for this would appear to be users wanting to run the generator against their own clusters.
https://github.com/kubernetes/kubernetes/blob/9d278e622427d307d50c1c2440b556005e2f8769/CHANGELOG/CHANGELOG-1.24.md#openapi-v3
Compare with the v2 schema to see if anything is documented more precisely, eg using
oneOfetc.https://github.com/kubernetes/kubernetes/tree/dfee09a27da7f409c46c37e0b93fe067eafa4ae9/api/openapi-spec/v3
(Refs: https://swagger.io/specification/ | https://datatracker.ietf.org/doc/html/draft-wright-json-schema-validation-00 )
The v3 schema doesn't seem to have much that's different from the v2 schema, let alone better.
oneOfis only used forio.k8s.apimachinery.pkg.api.resource.Quantityandio.k8s.apimachinery.pkg.util.intstr.IntOrString. The latter already has custom codegen. The former advertises itself as"oneOf": [{ "type": "string" }, { "type": "number" }], similar toIntOrString, but its documentation indicates one should always use the string form anyway, so the current codegen (newtype aroundString) might actually be preferable.Hacks like
JSONSchemaPropsOrArrayare still present, and still need to be treated in the same way."allOf"is only used with a single element in each use site, so it's not providing any new info, just associating the field / parameter with its type.Neither of the two extent "upstream bugs" have been fixed. GVK still references
NodeProxyOptionsetc that don't exist as definitions.connectCoreV1GetNamespacedPodExecstill annotates itscommandquerystring parameter as a single string.List operations still include watch operation parameters, so they still need to be split apart.
Any other validations that restrict values -
"enum", the various"min"and"max","pattern"etc - are not used anywhere.The schema is split into ~50 files, two per API group, and they all reference types from each other. This means a) lots of files would need to be downloaded instead of one
swagger.json, and b) a large portion of each would be redundant and need to be thrown away. Egio.k8s.apimachinery.pkg.apis.meta.v1.ObjectMetais defined identically in 24 files.So at this point the only reason to implement support for this would appear to be users wanting to run the generator against their own clusters.