-
-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kubernetes extensions #258
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey there,
(First off, thank you for your maintenance of schemars, it's really doing a lot of heavy lifting in the kube ecosystem where it's used everywhere - and it's more or less mandatory to derive
JsonSchema
on Kubernetes Custom Resources.)Background
Kubernetes has a bunch of small extensions to openapi schemas that they allow to be injected for special behaviour on the server-side.
Most of them are straight key-value such as
x-kubernetes-list-type: "set"
which we have been telling people to use#[schemars(schema_with ...)]
to override ala https://github.com/kube-rs/kube/blob/3a4f72414a4ad3733c2683514abff1924271759d/examples/crd_derive_schema.rs#L84-L102 to get the right behaviour in these special cases. This works, but it's a little awkward to deal with ergonomically (since you have to specify all the other properties manually - afaikt).In newer Kubernetes versions, these extensions are becoming more common and the new validation extension is expected to be the main way to do complex validation on the server-side via declarative rules going forward.
Question
I was wondering if you would be open to having feature-flagged
kubernetes
openapi extensions inschemars
to allow us to specify schemars attributes for the variousx-kubernetes
values?E.g. so we could do stuff like;
without having to use
schema_with
in quite so many places.The text was updated successfully, but these errors were encountered: