`response_types_map` not treated as an optional argument

[ndhansen]

Problem

Using kubernetes_asyncio.api_client.call_api without passing the argument response_types_map fails.

I would recommend skipping the reproduction I added below, as the bug is trivial and should be simple to understand in the "explanation" section.

Minimal reproduction

(Running inside a container on a k8s deployment, for simplicity.)

import kubernetes_asyncio as k8s
config = k8s.client.Configuration()
k8s.config.load_incluster_config(config)
with k8s.client.ApiClient(config) as api_client:
    await api_client.call_api("/readyz", "GET")

This fails with the error:

File "<snip>/kubernetes_asyncio/client/api_client.py", Line 201, in __call_api
response_type = response_types_map.get(response_data.status, None)
AttributeError: 'NoneType' object has no attribute 'get'

Explanation

The method call_api takes an optional argument response_types_map: def call_api(self, resource_path, ..., response_types_map=None, ...)

https://github.com/tomplus/kubernetes_asyncio/blob/master/kubernetes_asyncio/client/api_client.py#L330

This argument is passed on to the __call_api method: https://github.com/tomplus/kubernetes_asyncio/blob/master/kubernetes_asyncio/client/api_client.py#L121

In the __call_api method, the argument is not treated as optional: https://github.com/tomplus/kubernetes_asyncio/blob/master/kubernetes_asyncio/client/api_client.py#L201

response_type = response_types_map.get(response_data.status, None)

If response_types_map was not passed in (which it is not by default), this line fails, as response_types_map is None, not a dictionary.

Fix

Fixed in: https://github.com/tomplus/kubernetes_asyncio/pull/311

[tomplus]

Thanks, definitely it's worth to fix it :+1:

But I'm curious what's your use case, because usually this method is not called directly?

[ndhansen]

Sorry it took me so long to respond. I was working on some code where the use-case was to periodically send commands to kubernetes, but we wanted to check that the kubernetes cluster was ready first. Kubernetes exposes this through the readyz endpoint. Since there's no dedicated method for doing this in the kubernetes client, the next best solution was to use the call_api method.

[tomplus]

Fair enough, thanks.