kube-rs implements the HasSpec and HasStatus traits on CRDs generated with kube-derive macros. These are quite useful when writing generic code operating on arbitrary resources.
Unfortunately, k8s-openapi does not expose this information through its own traits for kube-rs to be able to provide a blanket impl of these traits for all k8s resources.
I'm aware that the OpenAPI schema unfortunately does not provide this information. However, from a quick check a heuristic as simple as a status/spec property referring to suffixed type name or mentioning the spec/status convention (https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) in its description would be sufficient.
I don't mind taking the time to make a PR for this if it's not something maintainers would be opposed to (e.g. due to the API schema not authoritatively exposing this information).
kube-rs implements the
HasSpecandHasStatustraits on CRDs generated withkube-derivemacros. These are quite useful when writing generic code operating on arbitrary resources.Unfortunately, k8s-openapi does not expose this information through its own traits for
kube-rsto be able to provide a blanket impl of these traits for all k8s resources.I'm aware that the OpenAPI schema unfortunately does not provide this information. However, from a quick check a heuristic as simple as a
status/specproperty referring to suffixed type name or mentioning the spec/status convention (https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) in its description would be sufficient.I don't mind taking the time to make a PR for this if it's not something maintainers would be opposed to (e.g. due to the API schema not authoritatively exposing this information).