[Tracking Issue] Pain points in using OpenAPIv2 schema

[yue9944882]

/kind feature
/sig api-machinery

@sttts @roycaihw @kubernetes/sig-api-machinery-misc

• Multi-types support:
  • (Getting exception from deleteNamespacedStatefulSet() call kubernetes-client/java#86) Delete calls returns actual objects in the response (e.g. when there's remaining finalizers) while the v2 spec says it's returning a status object.
  • (Passing V1Service and V1NetworkPolicy to CoreV1Api.replace methods can cause an API exception kubernetes-client/python#322, Generate valid openapi spec for intstr.IntOrString #62329) IntOrString cannot be correctly described in the v2 spec.
• Enum support
  • (Umbrella issue for OpenAPI v3 related improvements #60937 (comment)) The v2 spec doesn't say about the allowed values for fields like ImagePullPolicy.
• Model inheritance
  • make metav1.TypeMeta or metav1.Object a parent model for the openapi clients

[sttts]

enum and int-or-string is solved in v3.

My main question is: if we want to produce a v3 compatible spec using the go-openapi/spec types, what is missing?

[fedebongio]

/assign @roycaihw

[roycaihw]

thanks for listing the pain points. Can we fold the umbrella issues into a single one (we can use this one and close the others)?

#60937
#51163
#25716

[arianvp]

I have another painpoint here: dhall-lang/dhall-kubernetes#77

When doing code generation from the OpenAPI spec, objects that describe sum types like Volume are hard to generate code for because it's not clear from the spec of Volume that only one of the emptyDir, configMap, azureDisk, ... etc fields can be used.

[liggitt]

it's not clear from the spec of Volume that only one of the emptyDir, configMap, azureDisk, ... etc fields can be used.

see the union proposal in https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190325-unions.md#openapi

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[yue9944882]

/lifecycle frozen

for now it's pending under 1.18 milestone