Required arrays with null value

[mbohlool]

Looks like there is a problem with 1.8 spec going forward [TODO:ref issue] that an array that marked as required can be null. Assuming an empty array is an acceptable array in these situation (and it look like it is as kubernetes return empty array in some of those cases, TODO: add ref issues) we should consider fixing it in the main repo (TODO: create an issue) and also here as a quick fix until main repo issue has been fixed. This is my brain dump on the issue in case of anyone wants to work on this:

• we should first research the problem and see if that is the case for all required arrays or a subset of them
• as a quick fix, we can remove those arrays (or subset of them based on previous findings) from required list in a preprocessing step in this repo.
• A regeneration of python (and other languages) clients should fix the issues (TODO: ref those issues)
• Next, there should be a more permanent fix in the main repo.

[roycaihw]

Gathering known required API fields issues in python client:

• io.k8s.apimachinery.pkg.apis.meta.v1.APIVersions requires serverAddressByClientCIDRs (Error when trying to retrieve api versions python#418, get_api_group() raises ValueError: Invalid value for server_address_by_client_cid_rs, must not be None python#394, kubernetes.client.apis.apps_v1beta1_api.AppsV1beta1Api.get_api_resources() crashes on OpenShift 3.6 because of deserialization failure python#464)

  • serverAddressByClientCIDRs is required by server may return null as a valid response https://github.com/kubernetes/kubernetes/blob/9bd4f12c336af339c35e773e1d71a37cad342f57/staging/src/k8s.io/apiserver/pkg/server/genericapiserver.go#L407-L414
  • Fixed in Make serverAddressByClientCIDRs in discovery API optional kubernetes/kubernetes#61963

• v1beta1.CustomResourceDefinitionStatus requires conditions (allows null conditions, fixes #415 python#447)

• DisruptedPods in policy.v1beta1.PodDisruptionBudgetStatus (V1beta1PodDisruptionBudget deserialization should not throw exception on V1beta1PodDisruptionBudgetStatus python#466)

• extensions_v1beta1_deployment_rollback. Unrelated. There is a k8s pr fixing the wrong openapi spec. (v1beta1/create_namespaced_deployment_rollback python#491, Req: Example for deployment rollback python#427)

• involved_object in v1.Event. Unrelated. The bug is in watch client not handling HTTP error before unmarshaling Watch stream should handle HTTP error before unmarshaling event python-base#57 (Compatibility issue between K8s v1.9 and python client v5.0 python#484)

The issue started in release-4.0. Although we had the required-field validation generated since release-1.0, the api_client would assign [] for the null fields before deserialize the model (before release-3.0). Since release-4.0 the generated api_client doesn't convert null to empty array anymore, and the ValueError gets raised.

Agree that the problem is in our API convention (can an required array be null?), and there should be a permanent fix in the main repo.

[ceridwen]

There are a number of other API fields with this problem. From watching the issues in the two repositories in question, I have the following list. (This is just straight links, I don't have time right now to make the formatting pretty. I tried to avoid duplicates.)

Kubernetes

kubernetes-client/python#491
kubernetes-client/python#484
kubernetes-client/python#466
kubernetes-client/python#427
kubernetes-client/python#424

OpenShift

kubernetes-client/python#464
openshift/openshift-restclient-python#138

There are probably more that I haven't run into and that no one else has bothered to post an issue for yet.

[smiller171]

Looking at related issues (specifically #394) This has been an issue since at least November.

Is there any word on a fix or a workaround? As someone new to Kubernetes and even newer to the Python client, I have absolutely no idea how to move past this and make my application work.

[StephanX]

@smiller171 For good or ill, I've managed to work around this in my kubernetes-python module by commenting out the subject enforcement check at lines 184 & 185 of my /usr/local/lib/python3.6/site-packages/kubernetes/client/models/v1beta1_cluster_role_binding.py file (the content being):

        if subjects is None:
            raise ValueError("Invalid value for `subjects`, must not be `None`")

[djmckinley]

I just came across this issue with the "limits" array in the LimitRangeSpec resource. If I write a LimitRange object with an empty array, when reading it back, I get the exception: "Invalid value for limits, must not be None". I worked around it by catching those exceptions and dealing with them - but I'm wondering if removing the test raising the exception like StephanX did would be better.

This seems to be a serious, pervasive issue with at least the 5.0.0 library. Is that accurate, or am I misunderstanding something?

Is there any fix in the works? Or suggested workaround other than dealing with each and every occurrence? So far, in my project, we've had to implement workarounds for this limits case, and the PodDisruptionBudget case (kubernetes-client/python#466). This issue (#52) makes it appear there could be many more problems lurking out there. Do we need to give up on 5.0.0, and go back to an earlier stable library release?

[roycaihw]

Upstream PR fixing serverAddressByClientCIDRs: kubernetes/kubernetes#61963

[roycaihw]

Fixes for Conditions in CustomResourceDefinitionStatus kubernetes/kubernetes#64996
DisruptedPods in policy.v1beta1.PodDisruptionBudgetStatus kubernetes/kubernetes#65041

[lavalamp]

Given that apiserver ignores the rule today, everything just works better if we adjust the specs to mark these fields as optional, no?

[lavalamp]

Also, see kubernetes/kube-openapi#87

[mydockergit]

@roycaihw you can check v1beta1.CustomResourceDefinitionStatus requires conditions (kubernetes-client/python#447) because it is closed already.

[roycaihw]

@mydockergit The field is still marked as required, as openapi spec shows:

   "io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1beta1.CustomResourceDefinitionStatus": {
    "description": "CustomResourceDefinitionStatus indicates the state of the CustomResourceDefinition",
    "required": [
     "conditions",
     "acceptedNames",
     "storedVersions"
    ],

I think kubernetes-client/python#447 was closed because we want to fix the API upstream

[agassner]

Any luck with this?

[ikflc]

Hi There, I am running python 3.7.2 and hit the same problem trying to deploy sql aag onto AKS, by running "python ./deploy-ag.py ...".
←[31m[ERROR] ←[0mCaught exception: Invalid value for conditions, must not be None
←[31m[ERROR] ←[0m<bound method ApiextensionsV1beta1Api.list_custom_resource_definition of <kubernetes.client.apis.apiextensions_v1beta1_api.ApiextensionsV1beta1Api object at 0x04178A10>> Could not complete successfully.

But the AKS is created. Is there anything i need to do to fix up the errors and how?

Thanks & regards,
Irene

[NKUCodingCat]

It seems caused by the issue of type hinting or some other similar
I can monkey patch it in my code but it is too tricky in product environment
Is there any other way to work around it ?

@ikflc here's a quick but dirty patch

from kubernetes import client

# ======== Hack for V1beta1CustomResourceDefinitionStatus bug ==================
# Things happened in /site-packages/kubernetes/client/api_client.py:635
# We should override models.V1beta1CustomResourceDefinitionStatus to avoid "Empty conditions" error
# Such issue relates to https://github.com/kubernetes-client/gen/issues/52
# I have nothing to do but monkey patch it

class Hack_Status_Conditions(client.api_client.models.V1beta1CustomResourceDefinitionStatus):
    
    def __init__(self, *args, **kwargs):
        super(Hack_Status_Conditions, self).__init__(*args, **kwargs)
        
    @property
    def conditions(self):
        return super(Hack_Status_Conditions, self).conditions

    @conditions.setter
    def conditions(self, cond):
        self._conditions = list() if cond == None else cond

client.api_client.models.V1beta1CustomResourceDefinitionStatus = Hack_Status_Conditions

# =================== DONE hacking here ================================================

Test passed in Python 3.7.2 / Kubeclient-Python v9.0.0 / Kubernetes 1.13.5

[lavalamp]

@roycaihw looks like some of your fix PRs didn't get enough attention, maybe you can revisit them?

[zhangmingld]

@kubernetes/sig-api-machinery-bugs, we have the same problem
Can anyone help to look at this ?

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

[roycaihw]

/remove-lifecycle stale
/lifecycle frozen

[kierenj]

Am I running into this here, or shall I raise a separate issue? Code straight from one of the examples:

deployment = client.AppsV1beta1Deployment()

/opt/conda/lib/python3.6/site-packages/kubernetes/client/models/apps_v1beta1_deployment_spec.py in __init__(self, min_ready_seconds, paused, progress_deadline_seconds, replicas, revision_history_limit, rollback_to, selector, strategy, template)
     87         if strategy is not None:
     88           self.strategy = strategy
---> 89         self.template = template
     90 
     91     @property

/opt/conda/lib/python3.6/site-packages/kubernetes/client/models/apps_v1beta1_deployment_spec.py in template(self, template)
    294         """
    295         if template is None:
--> 296             raise ValueError("Invalid value for `template`, must not be `None`")
    297 
    298         self._template = template

ValueError: Invalid value for `template`, must not be `None`

[dweineha]

I get similar results when calling list_api_service():
ValueError: Invalid value for service, must not be None

However, service is None whenever a service is Local (which is most of them).

And when calling list_controller_revision_for_all_namespaces():
ValueError: Invalid value for raw, must not be None

RuntimeRawExtension is explicitly listed as [optional] in the documentation for V1ControllerRevision, but is treated as mandatory by the bindings.

I've only tested with version 10.1.0 of the bindings, but checking the source code for 11.0.0 seems to indicate that the issue is still there.