V1ServicePort.targetPort type changed from any to object in 0.10.3

[zen0wu]

An issue I noticed while upgrading.

It used to be any, which works fine. Now it's object, where giving a number would cause a type error.

https://github.com/kubernetes-client/javascript/blob/master/src/gen/model/v1ServicePort.ts#L37

[brendandburns]

Thanks for pointing this out. I'm not sure where that came from... I will dig in and see what we need to do to fix it.

Note that you can always pass the number as a string (e.g. "123") the code will do the right thing.

[zen0wu]

Thanks for responding. Passing as string doesn't pass the type check too, string doesn't conform to object. Probably need to use any.

[xogeny]

I found a similar issue with ExtensionsV1beta1IngressBackend. In that type definition, servicePort is listed as object but it should really be number | string. You can see where the confusion may be coming from if you look at the swagger.json code found here:

...
    "io.k8s.api.networking.v1beta1.IngressBackend": {
      "description": "IngressBackend describes all endpoints for a given service and port.",
      "properties": {
        "serviceName": {
          "description": "Specifies the name of the referenced service.",
          "type": "string"
        },
        "servicePort": {
          "$ref": "#/definitions/io.k8s.apimachinery.pkg.util.intstr.IntOrString",
          "description": "Specifies the port of the referenced service."
        }
      },
      "required": [
        "serviceName",
        "servicePort"
      ],
      "type": "object"
    },
...

Specifically, note the "$ref": "#/definitions/io.k8s.apimachinery.pkg.util.intstr.IntOrString",. I suspect that what ever automatic process is used to generate the TypeScript definitions, it gets confused by the $ref here and doesn't translate it into the correct type.

[cwardcode]

This is preventing me from being able to upgrade to 0.11.0 as well. Are there any updates as to when this will be resolved?

[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

[brendandburns]

/lifecycle frozen

[FreakyTurtle]

This issue is essentially making the node client unusable, cannot set an ingress because servicePort is incorrectly typed as object, cannot use a clusterIP because targetPort is incorrectly typed as object. Is there any update on this?🙏

[nicholascapo]

I am seeing the same problem with V1RollingUpdateDaemonSet.maxUnavailable
Neither string nor number are assignable to object.

javascript/src/gen/model/v1RollingUpdateDaemonSet.ts

Line 22 in 932c2fb

'maxUnavailable'?: object;

[ccravens]

For any others reading this, this is how I hacked my way around this issue:

port.targetPort = (8000 as unknown) as object;

[polaroi8d]

For any others reading this, this is how I hacked my way around this issue:

port.targetPort = (8000 as unknown) as object;

You are a real herooo 👍

[alex-bezek]

@brendandburns I noticed this issue linked in my teams code. I think it should be resolved now that #666 is merged