KeyError: 'object' while trying to get events for named Deployment

[hedin163]

What happened (please include outputs or screenshots):

I'm trying to get events on a specified resource with a specified name using DynamicClient and getting a KeyError if I specify a name of a resource (https://github.com/kubernetes-client/python-base/blob/b4d3aad42dc23e7a6c0e5c032691f8dc385a786c/dynamic/client.py#L153):

>>> from kubernetes import config, dynamic
>>> from kubernetes.client import api_client
>>> dyn_client = dynamic.DynamicClient(
...     api_client.ApiClient(configuration=config.load_kube_config())
...     )
>>> source_api = dyn_client.resources.get(api_version="apps/v1", kind="Deployment")
>>> for event in source_api.watch(resource_version=0, namespace='amatrenin-sandbox', name='source-nginx', timeout=60):
...     print(event['type'], event['object']['metadata']['creationTimestamp'], event['object']['metadata']['name'])   
... 
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/amatrenin/.local/lib/python3.8/site-packages/kubernetes/dynamic/client.py", line 174, in watch
for event in watcher.stream(
File "/home/amatrenin/.local/lib/python3.8/site-packages/kubernetes/watch/watch.py", line 169, in stream
event = self.unmarshal_event(line, return_type)
File "/home/amatrenin/.local/lib/python3.8/site-packages/kubernetes/watch/watch.py", line 98, in unmarshal_event
js['raw_object'] = js['object']
KeyError: 'object'

but everything is fine when I'm trying to get events without specifying a name (I have only one deployment in this namespace):

>>> for event in source_api.watch(namespace='amatrenin-sandbox', timeout=60):                    
...     print(event['type'], event['object']['metadata']['creationTimestamp'], event['object']['metadata']['name'])
... 
ADDED 2021-05-27T13:41:59Z source-nginx

maybe I'm doing something wrong or I have a misunderstading of name parameter for a watch method?

What you expected to happen:

Get events for a resource with an exact name I provide with DynamicClient methods, because I want to pass a resorce class name within args for my app I'm writing:
source_api = dyn_client.resources.get(api_version="apps/v1", kind=args.source_kind)
where source_kind can be one of {DaemonSet,Deployment,ReplicaSet,StatefulSet}

How to reproduce it (as minimally and precisely as possible):

create some deployments in a namespace and try to get events with watch method of DynamicClient with a specified name of resource

Anything else we need to know?:

Environment:

• Kubernetes version (kubectl version):
  Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:50:19Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.4", GitCommit:"d360454c9bcd1634cf4cc52d1867af5491dc9c5f", GitTreeState:"clean", BuildDate:"2020-11-11T13:09:17Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}

• OS (e.g., MacOS 10.13.6):
  Ubuntu 20.04.2 LTS

• Python version (python --version)
  Python 3.8.5

• Python client version (pip list | grep kubernetes)
  kubernetes 17.17.0

[roycaihw]

cc @fabianvf

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[bobh66]

I'm seeing this same issue - the problem appears to be that the get method returns the actual named object even when watch is set to true. The workaround is to use field_selector="metadata.name=foo" which filters on the desired object but allows the watch to work and return the expected data format.

I think the DynamicClient watch method should either not accept a name parameter and require the user to specify the desired field_selector, or do the translation:

if name:
    field_selector=f"metadata.name={name}"

and don't pass name to the stream() method.