Open Dav1dde opened 1 year ago
Currently testing this workaround in my setup:
// Removes all `nullable: true` occurences from the CRD.
//
// See https://github.com/kube-rs/kube/issues/1078
fn remove_nullable(crd: &str) -> String {
lazy_static::lazy_static! {
static ref RE: Regex = Regex::new(r"\s*nullable: true").unwrap();
}
RE.replace_all(crd, "").into_owned()
}
fn print_crd<T: CustomResourceExt>() -> eyre::Result<()> {
let crd = serde_yaml::to_string(&T::crd())?;
let crd = remove_nullable(&crd);
print!("{crd}");
Ok(())
}
Work to fix this was reverted in 0.82.1 due to unintended consequences. Users that want to fix this should opt-in to non_nullable behaviour (and we can probably offer a kube-derive attr for it like #[kube(non_nullable)]
).
On the other hand, it is also possible that upstream (i.e. kubectl) should handle legit schemas Kubernetes actually support better.
Current and expected behavior
The following definition:
Generates the CRD:
(Note: the only difference is the
nullable: true
field)Using
kubectl explain
we get this (descriptions etc. omitted):Further inspecting the fields.
Without Option:
With Option:
The type information is completely lost.
Possible solution
Omitting the
nullable: true
field from the Schema makes it explorable viakubectl explain
.This is obviously a major change potentially affecting every CRD generated with
kube
.Additional context
The problem seems to be described here:
The nullable behaviour described here, seems to indicate that this should be compatible with serde if we just never emit the
nullable
field.Environment
Configuration and features
Affected crates
kube-derive
Would you like to work on fixing this bug?
yes