python pod condition_type values are not consistent with actual possible values of kubernetes

What happened (please include outputs or screenshots): when trying to fetch pods (namespaced, cluster wide, or a single pod), when the pod status is not ['ContainersReady', 'Initialized', 'PodScheduled', 'Ready'] an exceptions is raised:

Traceback (most recent call last):
    pod_list = self.core_v1.list_namespaced_pod(namespace)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api/core_v1_api.py", line 15697, in list_namespaced_pod
    return self.list_namespaced_pod_with_http_info(namespace, **kwargs)  # noqa: E501
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api/core_v1_api.py", line 15812, in list_namespaced_pod_with_http_info
    return self.api_client.call_api(
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 348, in call_api
    return self.__call_api(resource_path, method,
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 192, in __call_api
    return_data = self.deserialize(response_data, response_type)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 264, in deserialize
    return self.__deserialize(data, response_type)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 303, in __deserialize
    return self.__deserialize_model(data, klass)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 639, in __deserialize_model
    kwargs[attr] = self.__deserialize(value, attr_type)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 280, in __deserialize
    return [self.__deserialize(sub_data, sub_kls)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 280, in <listcomp>
    return [self.__deserialize(sub_data, sub_kls)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 303, in __deserialize
    return self.__deserialize_model(data, klass)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 639, in __deserialize_model
    kwargs[attr] = self.__deserialize(value, attr_type)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 303, in __deserialize
    return self.__deserialize_model(data, klass)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 639, in __deserialize_model
    kwargs[attr] = self.__deserialize(value, attr_type)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 280, in __deserialize
    return [self.__deserialize(sub_data, sub_kls)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 280, in <listcomp>
    return [self.__deserialize(sub_data, sub_kls)
  File "/home/dan/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 303, in __deserialize
    return self.__deserialize_model(data, klass)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/api_client.py", line 641, in __deserialize_model
    instance = klass(**kwargs)
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/models/v1_pod_readiness_gate.py", line 52, in __init__
    self.condition_type = condition_type
  File "/home/.cache/pypoetry/virtualenvs/sosivio3-l1HFUjLL-py3.9/lib/python3.9/site-packages/kubernetes/client/models/v1_pod_readiness_gate.py", line 78, in condition_type
    raise ValueError(
ValueError: Invalid value for `condition_type` (www.dmlhgrdtdhzerjqa.com), must be one of ['ContainersReady', 'Initialized', 'PodScheduled', 'Ready']

What you expected to happen: The running pods in the namespace have the following Statuses: Terminating Running Pending ImagePullBackOff ErrImageNeverPull ErrImageNeverPull ErrImageNeverPull (this is the kubectl get pods status)

How to reproduce it (as minimally and precisely as possible): try to get pods in namespace with a non-straightforward status.

Anything else we need to know?: I think the Problem is that the possible enum values does not align with the actual values that are possible in kube.

Environment:

Kubernetes version (kubectl version): 1.23

$ oc version                                          
Client Version: 4.8.11
Server Version: 4.7.34
Kubernetes Version: v1.20.0+bbbc079

OS (e.g., MacOS 10.13.6): ubuntu 20.04
Python version (python --version) 3.9.2
Python client version (pip list | grep kubernetes) 23.3.0

Mar 23 '22 10:03 DanArlowski

Is this pod created by Custom Resource, www.dmlhgrdtdhzerjqa.com this condition type is customized?

Mar 24 '22 08:03 showjason

@showjason - This pod is from a standard deployment, but the deployment is not running (createconfigError, createSecretError, unknownpodstatus, etc)

this endpoint is not coming from the pod AT ALL - that means this pod is created using a standard apps/v1 deployment, and is managed by a replicaset, this domain exists in the python generated structure, but not in yaml defnitino of the pod AT ALL,

to make it even weirder - this domain is jumping on more than one pod & more than one namespace, do you think its something that is injected from anywhere in the k8s client stack?

Mar 24 '22 10:03 DanArlowski

@DanArlowski, you can describe this pod or get the pod's yaml template by kubectl to get more detailed info. Especially focus on Condition and ownerReference

Mar 25 '22 05:03 showjason

This is being fixed in upstream. We will cut a new 1.23 client to backport the fix once the PR https://github.com/kubernetes/kubernetes/pull/108740 is merged

Mar 28 '22 17:03 roycaihw

I think the upstream PR are merged, and the new client build could happen now, thank you in advance!

Apr 03 '22 20:04 aquam8

The new client can be generated when the upstream cuts a new patch release. Tracking in https://github.com/kubernetes-client/python/issues/1773.

Apr 09 '22 00:04 roycaihw

Also seeing this issue on EKS 1.21. specifically, using AWS Load Balancer Controller with pod readinessgates makes this client unusable.

May 05 '22 17:05 rdpa

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

Aug 03 '22 18:08 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

Sep 02 '22 18:09 k8s-triage-robot

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

This bot triages issues 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 with /reopen
Mark this issue as fresh with /remove-lifecycle rotten
Offer to help out with Issue Triage

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

/close not-planned

Oct 02 '22 18:10 k8s-triage-robot

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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 with /reopen

Mark this issue as fresh with /remove-lifecycle rotten

Offer to help out with Issue Triage

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

/close not-planned

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.

Oct 02 '22 18:10 k8s-ci-robot