Python: Key names don't match up with API

[Velyks]

The keys that are generated by kubernetes-client, both in the YAML response and using to_dict(), differ from the ones provided by the kubernetes API and all the tools that use it. It looks to mostly replace camelcase with underscores.

As I'm trying to use kubernetes-client to create diffs between exported YAML and the manifests in kubernetes this is causing me a lot of problems. Can we please have an option to use standard kubernetes naming for keys?

Some examples:

• api_version instead of apiVersion
• creation_timestamp instead of creationTimestamp
• self_link instead of selfLink
• node_port instead of port in Services

[micw523]

In one way I feel like what you need is a simple snake_case to camelCase parser;

In another way I went to check the JAVA client and saw their status output is the YAML/Json format that we can directly use. https://github.com/kubernetes-client/java/blob/master/kubernetes/src/main/java/io/kubernetes/client/models/V1Status.java

@roycaihw what are your thoughts?

[micw523]

/kind api-change

[tomplus]

Names are consistent with the Python naming convention.

@Velyks Could you give an example where to_dict() or raw YAML content don't work for you? Do you use _preload_content=False to get the raw response?

[micw523]

Ah. I didn't realize _preload_content exists.

[micw523]

/remove-kind api-change
/kind question

[AlexB138]

I'm struggling with this convention as well. I'm using the client to do some templating. Loading a running deployment with the client, and converting it with to_dict(), loads it in the snake_case format. Merging that content with a partial deployment loaded from a CRD, and therefore in the standard camelCase format, seems needlessly difficult.

_preload_content does seem like a viable escape hatch, but I agree a more direct function to translate into the API standard would be useful.

For those looking for a work around, my current strategy looks like this:

import json, kubernetes

...

response = v1_apps_api.list_deployment_for_all_namespaces(_preload_content=False) 
dep_list = json.loads(response.data)

[gree-gorey]

@tomplus here is an example when it does not work. I want to use client to generate templates (yaml or json) and then use kubectl apply. But using:

service = client.V1Service().to_dict()

generates this:

api_version: null
kind: null
metadata: null
spec: null
status: null

which is invalid for kubectl as it should be:

apiVersion: null
kind: null
metadata: null
spec: null
status: null

and I cannot use _preload_content=False in this case.

@micw523 we actually don't need snake_case to camelCase parser; all the objects already have attribute_map like this from v1_service.py:

attribute_map = {
        'api_version': 'apiVersion',
        'kind': 'kind',
        'metadata': 'metadata',
        'spec': 'spec',
        'status': 'status'
}

so we only need either change to_dict() method or introduce new method which would use this map to generate valid k8s json.
Generally, I could extend this class in my code and just add this method for the Service class for example, but method to_dict() is called recursively for nested objects, meaning that I would need to extend all possible classes form this client which is not that I would want to do :)

[gree-gorey]

390 provides a workaround, but still this is a workaround

[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

[fejta-bot]

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

[fejta-bot]

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

[k8s-ci-robot]

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

[Skillshot]

390 provides a workaround, but still this is a workaround

Just want to support the speaker on introducing a proper way of handling this issue.