int-or-string parameters are typed out with mismatched "type" property

[zlepper]

According to https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#intorstring types that are of the format "int-or-string" should be typed like this in the schema:

type: object
properties:
  foo:
    x-kubernetes-int-or-string: true

However right now they are typed as:

type: object
properties:
  foo:
     type: string
     format: int-or-string

While it probably isn't an issue most of the time, i'm encountering conflicts with reusing PodTemplateSpec, specially for httpGetAction for probes ends up like this:

                                          port:
                                            description: >-
                                              Name or number of the port to access on
                                              the container. Number must be in the
                                              range 1 to 65535. Name must be an
                                              IANA_SVC_NAME.
                                            type: string
                                            format: int-or-string

whereas they should probably end like this:

                                          port:
                                            description: >-
                                              Name or number of the port to access on
                                              the container. Number must be in the
                                              range 1 to 65535. Name must be an
                                              IANA_SVC_NAME.
                                            x-kubernetes-int-or-string: true

If left as is, you have to put quotes around the port number to be allowed to create an instance of a CRD resource with this property, however when you then try to create a pod from this spec, it will fail as quoted values are considered to the names of the named ports.

[Arnavion]

However right now they are typed as:

Yes, because that's what Kubernetes' own spec has always done:

https://raw.githubusercontent.com/kubernetes/kubernetes/v1.29.1/api/openapi-spec/swagger.json

    "io.k8s.apimachinery.pkg.util.intstr.IntOrString": {
      "description": "IntOrString is a type that can hold an int32 or a string.  When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type.  This allows you to have, for example, a JSON field that can accept a name or number.",
      "format": "int-or-string",
      "type": "string"
    },

... so I'm surprised it wants a different thing for user-provided specs.

[zlepper]

I agree, it's kinda f'ed up.. however it's probably another lovely case of Kubernetes not using crd's to represent its own stuff, and thus the behave differently :/