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

[j13tw]

Hi All, I think this is a issue of listed all Objects in a CRD Like the output of kubectl get <CRD> -o json shows kopium provides CRD conversion Struct provides k8s_openapi for use But when the items of k8s_openapi::List::default() map the CRD output will got some issue

The expected output behavior should be something like

It will appear the trait ``ListableResource`` is not implemented for <CRD-Name>

In my solution is following information needs to be added to achieve List output

According to k8s_openapi's impl / trait operations https://docs.rs/k8s-openapi/latest/k8s_openapi/struct.List.html https://docs.rs/k8s-openapi/latest/k8s_openapi/trait.ListableResource.html https://docs.rs/k8s-openapi/latest/k8s_openapi/trait.Resource.html

• impl the ListableResource && Resource

Resource Info is Mapping to Your CRD

• Add the derive Attribute on CRD Struct

For this Issue, Does anyone have a better solution?

[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