Current and expected behavior
Current Behaviour
Using kube-3.0.0, adding a comment to an Optional Enum field like so:
pub struct ListenerClassSpec {
/// With a doc-comment here, the CRD becomes invalid.
pub service_external_traffic_policy: Option<KubernetesTrafficPolicy>,
}
/// Doc comment
#[derive(Serialize, Deserialize, Clone, Debug, JsonSchema, PartialEq, Eq, strum::Display)]
pub enum KubernetesTrafficPolicy {
/// Doc comment
Cluster,
/// Doc comment
Local,
}...results in an invalid CRD (snippet):
serviceExternalTrafficPolicy:
anyOf:
- description: Doc comment
enum:
- Cluster
- Local
type: string
- enum:
- null
nullable: true
description: With a doc-comment here, the CRD becomes invalid.When applied to Kubernetes, it errors with the same thing from a previous issue:
❯ kubectl apply -f crates/stackable-operator/crds/ListenerClass.yaml
The CustomResourceDefinition "listenerclasses.listeners.stackable.tech" is invalid:
* spec.validation.openAPIV3Schema.properties[spec].properties[serviceExternalTrafficPolicy].anyOf[0].description: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[serviceExternalTrafficPolicy].anyOf[0].type: Forbidden: must be empty to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[serviceExternalTrafficPolicy].anyOf[1].nullable: Forbidden: must be false to be structural
* spec.validation.openAPIV3Schema.properties[spec].properties[serviceExternalTrafficPolicy].type: Required value: must not be empty for specified object fields
Expected Behaviour
Adding a comment should still produce a valid CRD as it used to (pre: kube 1.0.0).
Possible solution
Use the transformer implementation from the original unmerged PR.
Additional context
No response
Environment
N/A
Configuration and features
k8s-openapi = { version = "0.27.0", default-features = false, features = ["schemars", "v1_35"] }
kube = { version = "3.0.0", default-features = false, features = ["client", "jsonpatch", "runtime", "derive", "admission", "rustls-tls", "ring"] }YAML
No response
Affected crates
kube-core, kube-derive
Would you like to work on fixing this bug?
yes
Current and expected behavior
Current Behaviour
Using kube-3.0.0, adding a comment to an Optional Enum field like so:
...results in an invalid CRD (snippet):
When applied to Kubernetes, it errors with the same thing from a previous issue:
Expected Behaviour
Adding a comment should still produce a valid CRD as it used to (pre: kube 1.0.0).
Possible solution
Use the transformer implementation from the original unmerged PR.
Additional context
No response
Environment
N/A
Configuration and features
YAML
No response
Affected crates
kube-core, kube-derive
Would you like to work on fixing this bug?
yes