-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
typemeta is empty in all resource #541
Comments
decoding to go structs drops apiVersion/kind, because the type info is inherent in the object. decoding to unstructured objects (like the dynamic client does) preserves that information |
Somewhat related, I notice none of the types have struct tags for YAML:
} I'm trying to read in raw pod security policy in YAML (including kind, metadata, apiVersion) and Unmarshal unto a |
why does decoder clear GVK infos when deserialization?
|
Even through it is inherent, the object may later be used in a way so that the type information might not be easily accesible (or at all). Whereas the type meta information was already there and the client is doing extra work to just discard it, for no obvious reason. |
We are looking for the TypeMeta information for an object to be available as well because we are using that object as the owner reference for other objects being created in turn. Use Case:
Referencing @shsjshentao comment above Line 1075 in e65ca70
gvk being returned as well.
If someone can point us in the right direction, we don't mind creating a PR for this. |
@liggitt Please let me know if you'd like more clarification on the use-case above. Thanks. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
How to solve it? I can't get the information of typeMeta, but I haven't found a solution.
item.APIVersion is empty... |
Same issue here |
I figure I leave this here in-case anyone runs into this page when searching. I had this same issue when running tests (but connecting to a real cluster). When objects were created the TypeMeta would then be cleared (even if it was explicitly set beforehand). Long story short, I noticed that the client.Client being created in my tests differed from the one created with production code. The change that fixed it for me came down to when setting up the manager:
When I used "ctrl.GetConfigOrDie()" and then "manager.GetClient()" when setting up the reconcilers, this fixed it for me. Previously, I had been using "client.New" from package "sigs.k8s.io/controller-runtime/pkg/client" which is used in the generated scaffolded code from kubebuilder. Not sure why it differs, but hope it helps someone else out there having the same issue. |
Is there anyway to solve this? |
@liggitt @caesarxuchao |
Any update? |
…PIVersion As set out in issue kubevirt#9261 there have been reports of older VirtualMachineInstancetypeSpecRevision objects being stored in ControllerRevisions without APIVersion set. This is likely due to a known client-go issue [1] stripping TypeMeta from returned objects. Given the limited support for v1alpha1 and the fact that we moved away from VirtualMachineInstancetypeSpecRevision to complete objects being captured in ControllerRevisions by v1alpah2 this change simply works around this issue by ignoring the value of APIVersion. This should allow the conversion to complete correctly until we upgrade these ControllerRevisions in the future. [1] kubernetes/client-go#541 Signed-off-by: Lee Yarwood <lyarwood@redhat.com>
…PIVersion As set out in issue kubevirt#9261 there have been reports of older VirtualMachineInstancetypeSpecRevision objects being stored in ControllerRevisions without APIVersion set. This is likely due to a known client-go issue [1] stripping TypeMeta from returned objects. Given the limited support for v1alpha1 and the fact that we moved away from VirtualMachineInstancetypeSpecRevision to complete objects being captured in ControllerRevisions by v1alpah2 this change simply works around this issue by ignoring the value of APIVersion. This should allow the conversion to complete correctly until we upgrade these ControllerRevisions in the future. [1] kubernetes/client-go#541 Signed-off-by: Lee Yarwood <lyarwood@redhat.com>
…PIVersion As set out in issue kubevirt#9261 there have been reports of older VirtualMachineInstancetypeSpecRevision objects being stored in ControllerRevisions without APIVersion set. This is likely due to a known client-go issue [1] stripping TypeMeta from returned objects. Given the limited support for v1alpha1 and the fact that we moved away from VirtualMachineInstancetypeSpecRevision to complete objects being captured in ControllerRevisions by v1alpah2 this change simply works around this issue by ignoring the value of APIVersion. This should allow the conversion to complete correctly until we upgrade these ControllerRevisions in the future. [1] kubernetes/client-go#541 Signed-off-by: Lee Yarwood <lyarwood@redhat.com>
…PIVersion As set out in issue kubevirt#9261 there have been reports of older VirtualMachineInstancetypeSpecRevision objects being stored in ControllerRevisions without APIVersion set. This is likely due to a known client-go issue [1] stripping TypeMeta from returned objects. Given the limited support for v1alpha1 and the fact that we moved away from VirtualMachineInstancetypeSpecRevision to complete objects being captured in ControllerRevisions by v1alpah2 this change simply works around this issue by ignoring the value of APIVersion. This should allow the conversion to complete correctly until we upgrade these ControllerRevisions in the future. [1] kubernetes/client-go#541 Signed-off-by: Lee Yarwood <lyarwood@redhat.com>
…PIVersion As set out in issue kubevirt#9261 there have been reports of older VirtualMachineInstancetypeSpecRevision objects being stored in ControllerRevisions without APIVersion set. This is likely due to a known client-go issue [1] stripping TypeMeta from returned objects. Given the limited support for v1alpha1 and the fact that we moved away from VirtualMachineInstancetypeSpecRevision to complete objects being captured in ControllerRevisions by v1alpah2 this change simply works around this issue by ignoring the value of APIVersion. This should allow the conversion to complete correctly until we upgrade these ControllerRevisions in the future. [1] kubernetes/client-go#541 Signed-off-by: Lee Yarwood <lyarwood@redhat.com>
…PIVersion As set out in issue kubevirt#9261 there have been reports of older VirtualMachineInstancetypeSpecRevision objects being stored in ControllerRevisions without APIVersion set. This is likely due to a known client-go issue [1] stripping TypeMeta from returned objects. Given the limited support for v1alpha1 and the fact that we moved away from VirtualMachineInstancetypeSpecRevision to complete objects being captured in ControllerRevisions by v1alpah2 this change simply works around this issue by ignoring the value of APIVersion. This should allow the conversion to complete correctly until we upgrade these ControllerRevisions in the future. [1] kubernetes/client-go#541 Conflicts: pkg/instancetype/instancetype_test.go NOTE: The conflict was due to refactorings that were not applied to this branch. (e.g. renaming of variables) Co-authored-by: Felix Matouschek <fmatouschek@redhat.com> Signed-off-by: Lee Yarwood <lyarwood@redhat.com>
Generated client common methods does not return the GroupVersionKind of the resource. This is caused by kubernetes/client-go#541 and causes the goveralls job to constantly fails. While working of how to permanently fix it, let's reintroduce the explicit groupVersionKind set. Signed-off-by: fossedihelm <ffossemo@redhat.com>
Generated client common methods does not return the GroupVersionKind of the resource. This is caused by kubernetes/client-go#541 and causes the goveralls job to constantly fails. While working of how to permanently fix it, let's reintroduce the explicit groupVersionKind set. Signed-off-by: fossedihelm <ffossemo@redhat.com> (cherry picked from commit ae56ae3)
Generated client common methods does not return the GroupVersionKind of the resource. This is caused by kubernetes/client-go#541 and causes the goveralls job to constantly fails. While working of how to permanently fix it, let's reintroduce the explicit groupVersionKind set. Signed-off-by: fossedihelm <ffossemo@redhat.com> (cherry picked from commit ae56ae3)
@liggitt |
For those who stumbled upon this post. A quick and easy solution maybe: There is a util function Or use the low level functions in |
Previous code used `GroupVersionKind` method on actual resources to determine group/kind strings for them, but client-go unfortunately drops `TypeMeta` on resources processed by typed client (kubernetes/client-go#1328, kubernetes/client-go#541). Fortunately we know what types we build insights for, so we can use appropriate strings from client code for groups and hardcode kinds ourselves.
Previous code used `GroupVersionKind` method on actual resources to determine group/kind strings for them, but client-go unfortunately drops `TypeMeta` on resources processed by typed client (kubernetes/client-go#1328, kubernetes/client-go#541). Fortunately we know what types we build insights for, so we can use appropriate strings from client code for groups and hardcode kinds ourselves.
client-go/rest/request.go
Line 1107 in e6b0ffd
It is not only CRD and list resource, all resource has this issue.
I have tried 9.0 and 10.0 version.
K8S response is ok and contains "kind" and "apiVersion".
And after decoder, these two parameters has lost.
for json type, i can json.unmarshal to deal with this problem like
client.CoreV1().RESTClient().Get().Resource("pods").Name("nginx-controller-zwdhq").Namespace("default").DoRaw()
However, I want to use protobuf by
config.AcceptContentTypes = "application/vnd.kubernetes.protobuf,application/json"
Then no way to decode it properly.
Is it a bug and how to decode by protobuf with typemeta?
The text was updated successfully, but these errors were encountered: