Cannot pass configuration for the API query to reach specific object.

[gryf]

What happened (please include outputs or screenshots):

I have noticed, that every model class can accept local_vars_configuration parameter during creation, otherwise it create default one, i.e.:

    def __init__(self, api_version=None, items=None, kind=None, metadata=None, local_vars_configuration=None):  # noqa: E501
        """V1PodList - a model defined in OpenAPI"""  # noqa: E501
        if local_vars_configuration is None:
            local_vars_configuration = Configuration()
        self.local_vars_configuration = local_vars_configuration
        …

This lead to the title of this bug, where there is no way (or I cannot find one) for configuring an api call, to, for instance, turn off client side validation. In other words, there is no way to actually query K8s API with client side validation turned off.

I'm experimenting with the Kubernetes feature gate, and turned off selfLink propagation, which leads to an issue with the kubernetes itself, although IMO it just uncover how python client was designed.

My minimal example:

from kubernetes import client
from kubernetes.client import api_client
from kubernetes.client import configuration

conf = configuration.Configuration()
conf.client_side_validation = False

v1 = client.CoreV1Api(api_client=api_client.ApiClient(configuration=conf))
v1.list_pod_for_all_namespaces()

which just fetch the list of pods, and ends up wit the traceback:

Traceback (most recent call last):                                                                                                                                                                                 
  File "/home/ubuntu/official.py", line 11, in <module>
    v1.list_pod_for_all_namespaces()
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/api/core_v1_api.py", line 16864, in list_pod_for_all_namespaces
    return self.list_pod_for_all_namespaces_with_http_info(**kwargs)  # noqa: E501
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/api/core_v1_api.py", line 16981, in list_pod_for_all_namespaces_with_http_info
    collection_formats=collection_formats)
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/api_client.py", line 353, in call_api
    _preload_content, _request_timeout, _host)
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/api_client.py", line 192, in __call_api
    return_data = self.deserialize(response_data, response_type)
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/api_client.py", line 264, in deserialize
    return self.__deserialize(data, response_type)
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/api_client.py", line 303, in __deserialize
    return self.__deserialize_model(data, klass)
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/api_client.py", line 641, in __deserialize_model
    instance = klass(**kwargs)
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/models/v1_pod_list.py", line 63, in __init__
    self.items = items
  File "/usr/local/lib/python3.6/dist-packages/kubernetes/client/models/v1_pod_list.py", line 113, in items
    raise ValueError("Invalid value for `items`, must not be `None`")  # noqa: E501
ValueError: Invalid value for `items`, must not be `None`

What you expected to happen:

I'd expect, that configuration passed to the API object will be used in models as well. Otherwise there is no sense at all to configure anything connected with models itself, since default configuration would be used (not even preconfigured one, so set_default/get_default_copy methods of Configuration class could be used).

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

• run Kuberenetes <1.20 with --feature-gates=RemoveSelfLink=true
• use minimal example from above

Anything else we need to know?:

Environment:

• Kubernetes version (kubectl version): 1.19.6
• OS (e.g., MacOS 10.13.6): Ubintu 18.04 LTS
• Python version (python --version) 3.6.9
• Python client version (pip list | grep kubernetes) 12.0.1

[yliaog]

/assign @roycaihw

[joshuastagner]

I am hitting this exact issue when creating HPA objects. The initial status is None for a very short period which throws an exception. If client_side_validation was False, the None would pass through which is completely fine for my use case.

[roycaihw]

I think you're hitting the breaking change. Could you try using conf = Configuration().get_default_copy(), e.g. https://github.com/kubernetes-client/python/pull/1401/files?

[joshuastagner]

I have tried setting a new default Configuration with the attr client_side_validation = False using the set_default method but it isn't carried through to the model where the value I would like to set would prevent an exception. This is the exception I am getting. The Configuration is the initial config and not the default copy. Is there a way to modify the configuration for the Model so it will not raise the exception?

It seems like HPA objects are the only one that raises this error, and it is only seems to happen on initial create. Not sure if that is helpful

[roycaihw]

The HPA creation failing the validation must be another occurrence of kubernetes-client/gen#52. The condition field is marked as "required", but the apiserver is omitting it when responding. This can be fixed in upstream openapi spec. Please see kubernetes-client/gen#52 (comment) for an example fix.

[roycaihw]

using the set_default method but it isn't carried through to the model

I think this is a bug in the upstream client generator and was fixed in OpenAPITools/openapi-generator#8500. We need to bump the client generator version to include the fix.

[joshuastagner]

using the set_default method but it isn't carried through to the model

I think this is a bug in the upstream client generator and was fixed in OpenAPITools/openapi-generator#8500. We need to bump the client generator version to include the fix.

I think this looks like the exact fix I was hoping for! For the time being, I will catch the ValueError exception accordingly. Thanks @roycaihw

[roycaihw]

Filed #1421 to track bumping the version in the next prerelease.

[fejta-bot]

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-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.