-
Notifications
You must be signed in to change notification settings - Fork 6
Description
A thing that can be done in parallel to the implementation of the code-generation, is to sketch out the traits we need to implement in the codegen, and whether we need to rethink them a bit.
There is currently a bit of a disparity between k8s-openapi traits and kube_core's traits, and it would be nice if the traits we used in kube, were the traits defined either by kube_core or something here.
So here's a rough list of generics I think we should aim to implement / refine for this project to be successful:
wanted traits
Need at least these two to be able to implement kube::Resource upstream:
-
k8s-openapi::ResourceScopeequivalent. from old issue Resources are not scoped kube#194 - done in Add scope to theResourcetrait #25 -
k8s-openapi::Resourceequivalent - Add Traits #14 + Add scope to theResourcetrait #25
getter traits
-
HasSpecandHasStatus: https://github.com/kube-rs/kube-rs/blob/master/kube-core/src/object.rs - Add Traits #14 -
HasConditions: needed for things like Generic wait-for-condition Condition kube#679 - Add Traits #14 -
HasMetadata:: an analogue of thek8s_openapi::Metadatatrait - Add Traits #14
There are probably room for more things, but we should decide where generics should live.
Here? Or separate repo? I'm leaning towards defining a kube-traits crate within the kube-rs org and implementing it here.
But open to ideas. Also, anything missing from this list?
Descoped
These could maybe be done later for even more generic action.
- verb traits for subresources (e.g.
Log- these should probably not live inkube-client) - verb traits for normal resources - enables neokubism Project Neokubism kube#594
Metadata
Metadata
Assignees
Labels
Type
Projects
Status