CRD can't use on k8s_openapi::List, when it not trait.

[kube-rs]

CRD can't use on k8s_openapi::List, when it not trait.

[clux]

I think that's probably the current minimal if you want to use k8s_openapi's api feature.

The #[kube] instrumentation we provide in kopium is meant to simplify the use with kube::Api which can then be used as:

use kube::{Api, Client, ResourceExt};
use crate::generated::VirtualService;

let client = Client::try_default().await?;
let api: Api<VirtualService> = Api::default_namespaced(client);
for vs in api.list(&Default::default()).await? {
   println!("virtualservice: {}", vs.name());
}

it's mostly incidental that it provides any k8s-openapi trait implementations at all.

If you prefer to use k8s-openapi directly you might want to turn off the #[kube] insturmentation with kopium --hide-kube, to avoid needing to depend on kube if you are not using it for its client feature.

If you are also using kube, is there any reason why you use the k8s-openapi client?

[j13tw]

Hi clux, Thanks your Reply

In fact I use k8s_openapi
Mostly because it provides basic K8S Kind Struct support
(like Pod / Node / NS ... etc.)
And I need the CRD part to support the List output function
The List defined by kube-rs only has the metadata / items field
Relative to the kubectl get <CRD> -o json operation
will be missing kind / version information
I think these two should be standard API will have the opportunity to use
So use k8s_openapi to reproduce List functionality

[clux]

I am curious about your List issue there as neither:

• k8s-openapi::List
• kube::core::object::ObjectList

has kind/version on the list wrapper struct, there's only TypeMeta on the elements inside .items.
historically the apiserver did not use to return apiVersion and kind at all in list calls, but i see it does generate {"apiVersion": "v1", "kind": "List", ...} now. Is this something that is useful for you? We could open an issue in kube and solve it there if it's now guaranteed by the apiserver.

[j13tw]

Thanks for your reply
I'm also very interested in this plan
It will help me a lot
Because kubectl outputs -o yaml information
It appears to be fixed given { "apiVersion": "v1", "kind": "List" }
At present, not sure whether API Server can directly provide List return
So I not sure this is extend data overwrite with kubectl or not