Python: list_api_service: ValueError: Invalid value for `service`, must not be `None`

Created on 29 May 2020  路  8Comments  路  Source: kubernetes-client/python

Hello,
I try to get apiservice using in python doing:

config.load_kube_config(kubectl_config_full_path)
api_instance = client.ApiregistrationV1Api()
response = api_instance.list_api_service()
print("Api services: " + str(response))

but I get the following error:

ValueError: Invalid value for service, must not be None

I have a AWS EKS 1.15 as Kubernetes Master.
Python 3.6.8.
python kubernetes client 10.0.0
Ubuntu 16.04.6 LTS

Update:
I've tested it with python kubernetes client 11.0.0 and I get the same error

kinbug lifecyclrotten

Most helpful comment

Looks like this is another occurrence of https://github.com/kubernetes-client/gen/issues/52 and has been fixed by https://github.com/kubernetes/kubernetes/pull/85728 in Kubernetes 1.18. Kubernetes sometimes incorrectly restricts a field to be required but the apiserver may omits the field in real responses. These responses break the generated clients since the generated client-side validation expects the required field to exist.

For now the workaround is either to avoid de-serializing the response so the client-side validation doesn't kick in, or to remove the client-side validation if you have access to your local module code. Once we cut a new release with the 1.18 openapi spec, the generated client won't expect the field to be required.

All 8 comments

I was able to reproduce it locally.
I'll take a look at the code and figure out what needs to be done.
/assign

@clausa20 I've started looking into it, and for now I have workaround on how to make this work without failing.
If you add _preload_content=False as a kwarg to your function call, you can then get the list using response.data, as following:

    kubernetes.config.load_kube_config()
    api_registration_api = kubernetes.client.ApiregistrationV1Api()
    response = api_registration_api.list_api_service(_preload_content=False)
    print(response.data)

I'll keep looking into why the data serialization fails and figure out if this is an intended behavior or something that requires fixing and will act accordingly. But I hope that I was able to get you unblocked for now.

@MoShitrit thanks for the workaround, it fits ok for me. Regards.

Looks like this is another occurrence of https://github.com/kubernetes-client/gen/issues/52 and has been fixed by https://github.com/kubernetes/kubernetes/pull/85728 in Kubernetes 1.18. Kubernetes sometimes incorrectly restricts a field to be required but the apiserver may omits the field in real responses. These responses break the generated clients since the generated client-side validation expects the required field to exist.

For now the workaround is either to avoid de-serializing the response so the client-side validation doesn't kick in, or to remove the client-side validation if you have access to your local module code. Once we cut a new release with the 1.18 openapi spec, the generated client won't expect the field to be required.

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-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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.

Was this page helpful?
0 / 5 - 0 ratings