Client-go: typemeta is empty in all resource

Created on 8 Jan 2019  路  9Comments  路  Source: kubernetes/client-go

https://github.com/kubernetes/client-go/blob/e6b0ffda95bb53fab6259ebc653a0bbd3e826d9d/rest/request.go#L1107

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?

lifecyclstale

Most helpful comment

How to solve it? I can't get the information of typeMeta, but I haven't found a solution.

item, err := clientSet.BatchV1beta1().CronJobs(namespaceName).Get(context.TODO(), resourceName, metav1.GetOptions{})
item.APIVersion is empty...

All 9 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:
type PodSecurityPolicy struct { metav1.TypeMetajson:",inline" yaml:",inline" // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata // +optional metav1.ObjectMetajson:"metadata,omitempty" yaml:"metadata" protobuf:"bytes,1,opt,name=metadata"`

// spec defines the policy enforced.
// +optional
Spec PodSecurityPolicySpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`

}
`

I'm trying to read in raw pod security policy in YAML (including kind, metadata, apiVersion) and Unmarshal unto a v1beta1.PodSecurityPolicy. Would it be worth adding struct tags or just use the dynamic client? This seems to work when I modify locally, but not sure if this is a good approach.

why does decoder clear GVK infos when deserialization?

// Decode does not do conversion. It removes the gvk during deserialization.
func (d DirectDecoder) Decode(data []byte, defaults *schema.GroupVersionKind, into runtime.Object) (runtime.Object, *schema.GroupVersionKind, error) {
    obj, gvk, err := d.Decoder.Decode(data, defaults, into)
    if obj != nil {
        kind := obj.GetObjectKind()
        // clearing the gvk is just a convention of a codec
        kind.SetGroupVersionKind(schema.GroupVersionKind{})
    }
    return obj, gvk, err
}

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

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:

  1. We have a CRD for MyObject.
  2. We get an OnAdd(myObj)
  3. We need to create a Deployment (myDeployment) with OwnerReference pointing to the myObj. The OwnerReference requires the following information: Kind, ApiVersion, Name & UID. We are missing the Kind and ApiVersion from TypeMeta.
  4. If we delete the CRD directly, then we expect the instance myObj to be deleted but we also want myDeployment to be deleted as well.

Referencing @shsjshentao comment above
https://github.com/kubernetes/client-go/issues/541#issuecomment-479394147
We noticed that the Decode function does clear out the GVK information but does return it. However, in a call to Decode for example here, https://github.com/kubernetes/client-go/blob/e65ca70987a6941be583f205696e0b1b7da82002/rest/request.go#L1075 we ignore the 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.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

How to solve it? I can't get the information of typeMeta, but I haven't found a solution.

item, err := clientSet.BatchV1beta1().CronJobs(namespaceName).Get(context.TODO(), resourceName, metav1.GetOptions{})
item.APIVersion is empty...

Same issue here

Was this page helpful?
0 / 5 - 0 ratings

Related issues

antoineco picture antoineco  路  6Comments

AdheipSingh picture AdheipSingh  路  5Comments

tamalsaha picture tamalsaha  路  3Comments

vklonghml picture vklonghml  路  4Comments

peterwillcn picture peterwillcn  路  5Comments