-
Notifications
You must be signed in to change notification settings - Fork 39.6k
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
Decoding should not clear apiVersion/kind #80609
Comments
If the apiVersion is not specified, GroupVersoinKind can be dropped when decoding the data. Anyway, I will dig more about related issues before filing a PR. |
I think dropping WithoutVersionDecoder might be sufficient to accomplish this. I am looking into fixing #3030 in conversion, and adding tests to ensure conversion populates the apiVersion/kind appropriately |
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. |
Is there a real million stone for this issue? I see you moved this from v1.19 to v1.20 Although typed resource is already known to user, it's a bit weird to explicitly remove the GVK from de-serialized struct. |
It's not on my list of items to push on for 1.22. If someone wanted to pick up #80618 (or an alternate approach) and resolve the items I identified, that would be excellent. |
/reopen I doubt a PR to cluster-api fixed this |
/triage accepted |
Description of changes: Some version of K8s do not reliably return `TypeMeta` information when you call `apiReader.Get()` (see kubernetes/kubernetes#3030 and kubernetes/kubernetes#80609). This is a [known bug](kubernetes-sigs/controller-runtime#1517) in `controller-runtime` that they don't plan on fixing. Parts of the code, namely around setting up the user agent, currently rely on these fields - and they are currently being given an empty struct (with empty strings for all values). To work around this bug, this PR has introduced a new `GroupVersionKind()` getter in the `ResourceDescriptor` (replacing the existing `GroupKind`), which returns a static description of the GVK. Then, rather than referencing the `RuntimeObject` `TypeMeta` properties, we can reference this new GVK getter anywhere in the runtime. It also replaces any existing use of `GroupKind` to now use `GroupVersionKind`. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
HI folks, this issue makes it not possible properly test the controllers. Any idea when it would be fixed? Could we try to add some labels as a priority or add them in the next milestone? |
We can add priority/milestone labels but they only indicate intended priority/milestone, if nobody is signing up to fix this issue adding the label/milestone won't do anything and the milestone would be misleading. With ~2k issues in this repo alone, it's hard to get to everything. This one is marked "help wanted" so I think the SIG Owners are looking for someone to pitch in #80609 (comment) |
/reopen |
Is there any progress on this issue? |
This patch adds GVK into the bootstrap secret resources during backup, so that they can be recreated successfully during the restore. It appears that the Decoder used for getting K8s core resources clears the GVK info (see kubernetes/kubernetes#80609 for more details). - CloudInit with inlined secret data ``` $ govc vm.info -e "test-ubuntu-impish-inlined-cloud-config" | grep "vmservice.virtualmachine.additional.resources.yaml" | awk '{print $2}' | base64 -d | gunzip apiVersion: v1 kind: Secret ... ``` - Sysprep with inlined secret data ``` $ govc vm.info -e "test-windows-inlined-sysprep" | grep "vmservice.virtualmachine.additional.resources.yaml" | awk '{print $2}' | base64 -d | gunzip apiVersion: v1 kind: Secret ...
Since decoding clears the apiversion and kind information (kubernetes/kubernetes#80609), the index does not work consistently.
What would you like to be added:
When using a typed client, decoding to a versioned struct (not an internal API type), the apiVersion/kind information returned from the server should not be dropped.
Why is this needed:
The
GroupVersionKind()
method included in the ObjectKind interface is largely useless when dealing with arbitrary runtime.Object instances, since typed instances drop this information here:kubernetes/staging/src/k8s.io/apimachinery/pkg/runtime/helper.go
Lines 245 to 259 in 69a34f6
This is the decoder used when a client requests a decoder that does not do conversion:
kubernetes/staging/src/k8s.io/apimachinery/pkg/runtime/serializer/codec_factory.go
Lines 175 to 179 in 69a34f6
I could see clearing group/version/kind information when converting to an internal version, but I don't see the benefit of stripping it on decode if we're only dealing with a versioned struct.
/sig api-machinery
/cc @smarterclayton
Note that #3030 still needs to be resolved before apiVersion/kind could be depended on for individual objects for all API responses, but this would at least solve the issue with an update of an object clearing the apiVersion/kind in an update response (xref kubernetes-sigs/controller-runtime#526)
The text was updated successfully, but these errors were encountered: