KubernetesObjectApi does not properly return typed objects

[schrodit]

Describe the bug
When using the general KubernetesObjectApi the objects are not returned as typed objects as defined in the api definitions (https://github.com/kubernetes-client/javascript/tree/master/src/gen/api), but rather the plain json value is returned.

** Client Version **
e.g. 0.16.3

** Server Version **
e.g. 1.21.0

To Reproduce

see code snippet

Expected behavior
I expect that known objects are returned with their proper types.

** Example Code**

const k8s = require('@kubernetes/client-node');

const kc = new k8s.KubeConfig();
kc.loadFromDefault();

const k8sApi = kc.makeApiClient(k8s.CoreV1Api);
const client = kc.makeApiClient(k8s.KubernetesObjectApi);

client.list('v1', 'Pod', 'default').then(res => {
    const p = res.body.items[0];
    console.log(typeof p.metadata.creationTimestamp); // "string"
})

k8sApi.listNamespacedPod('default').then((res) => {
    const p = res.body.items[0];
    console.log(typeof p.metadata.creationTimestamp.getTime()); // "Object" --> Date
});

Environment (please complete the following information):

• OS: [e.g. Linux]
• NodeJS Version [eg. 16]

Enhancement Proposal

I guess that the current behavior is intended to also support unknown objects.
Also one can currently work around the described issue by using the ObjectSerializer like that

const k8s = require('@kubernetes/client-node');
const res = await client.read({apiVersion: 'v1', 'kind': 'Pod', metadata: {'name': 'a', 'namespace': 'default'}});
const pod = res.body; // type: KubernetesObject
pod.metadata.creationTimestamp // type "string"

const p = ObjectSerializer.serialize(pod, 'V1Pod');

But I think there could be a good opportunity to simplify the way the generic client can be used and improve the typing
Maybe something like that:

class KubernetesObjectApi {
    public read<T extends KubernetesObject | KubernetesObject>(spec: T, ...): {res: http.response, body: T} {
        // do the stuff that is currently done
        return this.requestPromise(localVarRequestOptions, this.getKnownType(spec));
    }
    
    private getKnownType(spec: KubernetesObject): string {
      // get type from spec + V1APIResource
    }

}

const spec: V1Pod = {apiVersion: 'v1', 'kind': 'Pod', metadata: {'name': 'a', 'namespace': 'default'}};
const res = await client.read(spec);
const pod = res.body; // type V1Pod
pod.metadata.creationTimestamp // type "Date"

Further this example might be enhanced so that even custom types could be added to the known types that the ObjectSerializer can also serialize CRDs.

[brendandburns]

I think that there are two different things here:

The first is that the generic API (KubernetesObjectApi) is indeed intended for unknown types. The generated APIs (e.g. CoreV1Api return strongly typed objects for known objects)

I'm not sure I follow the issue with the creationTimestamp. That object is a Javascript Date (https://github.com/kubernetes-client/javascript/blob/master/src/gen/model/v1ObjectMeta.ts#L32) you are calling the getTime() function on that Date object and then getting the typeof the result (which afaik is a number)

Any improvements that you want to make in KubernetesObjectApi would be welcome, please send a PR and we can discuss in that PR. I don't think anything is needed for the strongly typed objects.

[schrodit]

The first is that the generic API (KubernetesObjectApi) is indeed intended for unknown types. The generated APIs (e.g. CoreV1Api return strongly typed objects for known objects)

That was also my assumption, but I think It would b also beneficial if the generic api returned stringly typed objects for known types.
The use case is that one client has to used instead of a client for every apigroup e.g. CoreV1Client, AppsV1Client, etc..
This simplifies code where different clients are needed and need to passed around.

I'm not sure I follow the issue with the creationTimestamp. That object is a Javascript Date (https://github.com/kubernetes-client/javascript/blob/master/src/gen/model/v1ObjectMeta.ts#L32) you are calling the getTime() function on that Date object and then getting the typeof the result (which afaik is a number)

Too be clearer here.
The issue is that when the genric client is used, the creationTime is not a date but a string (contrary to the defined type KubernetesObject).
E.g.

const k8s = require('@kubernetes/client-node');

const kc = new k8s.KubeConfig();
kc.loadFromDefault();


const client = kc.makeApiClient(k8s.KubernetesObjectApi);

client.list('v1', 'Pod', 'default').then(res => {
    const p = res.body.items[0];
    console.log(typeof p.metadata.creationTimestamp); // "string" should be Date according to the "KubernetsObject" type
})

Anyway I will create a PR and we can discuss the improvements there.

[k8s-triage-robot]

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

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

[k8s-ci-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.

[schrodit]

/reopen

[k8s-ci-robot]

@schrodit: Reopened this issue.

In response to this:

/reopen

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-sigs/prow repository.