-
-
Notifications
You must be signed in to change notification settings - Fork 297
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
Generate schema for CRD v1 #348
Conversation
fa706cb
to
2aeee34
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC Kubernetes requires its own weird dialect of JSON Schemas. In particular, it has some weird requirements around tagged unions (which we'd generally use rich enums for in Rust).
Can schemars generate schemas that are compliant with that? If so, what special options are required for that?
@teozkr Thanks for reviewing. I just pushed a fix to support nested struct/enums and that also includes the status subresource automatically if present.
Yes, they use Open API v3 (dialect of JSON Schemas) with additional restrictions. I wasn't aware of the requirements around tagged unions. I'll try adding some.
|
BAD allOf:
- properties:
foo:
... GOOD properties:
foo:
...
allOf:
- properties:
foo:
... 😕 For the following spec (attributes omitted for brevity): pub struct FooSpec {
value: FooEnum,
}
#[serde(untagged)]
pub enum FooEnum {
Foo { foo: String },
Bar { bar: String },
} The generated schema currently looks like the following: openAPIV3Schema:
type: object
properties:
spec:
properties:
value:
anyOf:
- properties:
foo:
type: string
required:
- foo
type: object
- properties:
bar:
type: string
required:
- bar
type: object
required:
- value
type: object
required:
- spec
I'm not sure what's valid in this case, but I think we can transform the schema by implementing a let gen = schemars::gen::SchemaSettings::openapi3()
.with(|s| {
s.inline_subschemas = true;
})
.with_visitor(KubeVisitor::new())
.into_generator(); |
|
This is huge @kazk . Thank you so much for doing this. 🥳 Using There are a couple of things I would like to have tests for and clarify before we release this though:
Of course; I am happy to take this into master without further changes right now. This is a massive improvement, so thank you again. But if you are able to help a little bit with the general user experience, that would be super helpful :-) |
@clux Thanks for reviewing. Yeah, this definitely need more polishing. Also, we need to ensure generating a structural schema for more complex specs (should be a separate PR). But
There's an issue open and the author wrote:
So maybe it can be supported relatively easily. I'll look into the points you brought up later. It's getting late here. |
2f4ff7b
to
436f7ab
Compare
I did some research on generating more complex schemas and it turns out
So, it might not be limiting as I thought. (But I also think that Rust code is more likely to need this.) I'll finish the examples/tests either tonight or tomorrow. |
188b8b0
to
01e3a3c
Compare
01e3a3c
to
da68469
Compare
Schema is generated with `schemars`. `inline_subschemas` option is used to avoid definitions in schema. `meta_schema` is set to `None` to prevent including `$schema` which is not allowed by Kubernetes. This support nested structs and enums, but does not support structural schemas for some of the more complex spec types. The schema of the status subresource is included if present. Also fixed the location of `subresources` and `additionalPrinterColumns`. Closes kube-rs#264
47474d9
to
8b69d8a
Compare
@clux I cleaned up the commits and it should be ready for merge. Please let me know if I missed anything or if there's something you'd like to be fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is absolutely awesome. Tests seem to cover things well, I'll add them to the circleci config so that it sticks around.
Left a small request for chrono feature, I think it will "just work", but if it's in any way complicated, just say so, and I'll merge this as is!
Testing `chrono` feature.
Looking good. Ready to merge? :-) |
Yeah :) |
Thanks again for all of this. I'm planning to get a release out on Wednesday with some release notes for this. I'll post when it's done. |
Schema is generated with
schemars
.Also fixed the location of
subresources
andadditionalPrinterColumns
.Closes #264
For deriving CRD v1, the spec struct must include
schemars::JsonSchema
.The schemas for subresources are currently not generated, but it should be possible to add the status subresource by requiring the status struct to haveIf there is a status subresource, its struct must includeschemars::JsonSchema
and extracting the generated schema similar to the spec.JsonSchema
as well.I'm not sure how to handle the new
schemars
dependency.