CustomResourceDefinition Serialization | x-kubernetes-int-or-string Dropped

[sebastianserrano]

Describe the bug

When trying to create a CRD with x-kubernetes-int-or-string, its being dropped causing the server to respond with The CustomResourceDefinition "middlewares.traefik.io" is invalid: spec.validation.openAPIV3Schema.properties[spec].properties[circuitBreaker].properties[checkPeriod].type: Required value: must not be empty for specified object fields.

Original CRD

original.yaml

Broken CRD

broken.yaml

This is what is actually being passed to the server. How do I know? I print it out before sending the request in the underlying node_module, node_modules/@kubernetes/client-node/dist/object.js

Client Version
1.0.0 to 1.3.0

Server Version
1.30.0 to 1.33.0

To Reproduce
Steps to reproduce the behavior:

First option

1. Use example code

Second option

1. kubectl apply -f [USE HERE BROKEN CRD YAML]

^^ These are the errors you get while using the first option

Expected behavior

The create call should not strip out x-kubernetes-int-or-string. In essence, it should replicate the behaviour of kubectl apply -f [USE HERE ORIGINAL CRD YAML] which successfully creates the resource

Example Code

import yaml from 'yaml';
import * as k8s from '@kubernetes/client-node';

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

const client = k8s.KubernetesObjectApi.makeApiClient(kc);
const spec = yaml.parse(USE HERE ORIGINAL CRD YAML).toJS()

await client.create(spec);

Environment (please complete the following information):

• OS: Linux
• Node.js version: v20.14.0

Additional context
Add any other context about the problem here.

[brendandburns]

So the field is definitely there:

https://github.com/kubernetes-client/javascript/blob/main/src/gen/models/V1JSONSchemaProps.ts#L83

Have you tried outputting the spec in your sample code? You are using the yaml library which is not part of this library. My guess is that it is handling the x-... field name in some other way than the code expects. The code expects underscores instead of dashes, since dash syntax isn't legal in Javascript/Typescript.

[sebastianserrano]

Thanks for you reply @brendandburns. Here is what I've gathered:

1. Have you tried outputting the spec in your sample code? You are using the yaml library which is not part of this library.
   • Yes, if I print out what yaml produces, I can still see the x-kubernetes-int-or-string: true

2. I have another CRD which is being applied correctly, without having its x-kubernetes-int-or-string: true stripped out.

good.yaml

3. These are the differences between both
   • middlewares.traefik.io (broken)
     • x-kubernetes-int-or-string: true at path: .spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.circuitBreaker.properties.checkPeriod.x-kubernetes-int-or-string
   • ingressrouteudps.traefik.io
     • x-kubernetes-int-or-string: trueat path: .spec.versions[0].schema.openAPIV3Schema.properties.spec.properties.routes.items.properties.services.items.properties.port.x-kubernetes-int-or-string

Given these details, it seems like the behaviour should be predictable across the board? Either the serialization keeps all of the instances of x-kubernetes-int-or-string found or not.

Thoughts?

[sebastianserrano]

So the field is definitely there:

https://github.com/kubernetes-client/javascript/blob/main/src/gen/models/V1JSONSchemaProps.ts#L83

Have you tried outputting the spec in your sample code? You are using the yaml library which is not part of this library. My guess is that it is handling the x-... field name in some other way than the code expects. The code expects underscores instead of dashes, since dash syntax isn't legal in Javascript/Typescript.

Also, using

 import * as k8s from '@kubernetes/client-node';
 k8s.loadYaml<KubernetesObject>(ORIGINAL CRD HERE)

has the same effect as using the yaml package. It simply keeps x-kubernetes-int-or-string as is

[sebastianserrano]

I can see the reason why this wasn't popping up before is because everything was getting serialized as a KubernetesObject.

Starting in 1.0.0 that seemed to change

[brendandburns]

1.0.0 introduced a new code generator, so changes/bugs are expected. We'd be happy to look at PRs to fix/improve things.

[brendandburns]

Also, 1.0.0 forked off of the 0.x branch and stayed forked for a while under development, so it is also possible that previous fixes/updates in the 0.x branch weren't properly picked up for the 1.0 series.

[gastoner]

From my observations, the issue has started appearing from 1.1.2 -> 1.2.0 in #2400

[feloy]

In the serializer, there is a confusion between the attributeType.name and attributeType.baseName:

https://github.com/kubernetes-client/javascript/blob/1.3.0/src/gen/models/ObjectSerializer.ts#L2256

                instance[attributeType.baseName] = ObjectSerializer.serialize(data[attributeType.name], attributeType.type, attributeType.format);

For x-kubernetes-int-or-string attribute (and similar x* attributes), name is x_kubernetes_int_or_string and baseName is x-kubernetes-int-or-string, and data contains the field x-kubernetes-int-or-string, not the other one.

There are a few other attributes in V1JSONSchemaProps with name different from baseName, and I'm not sure which one we should get in this case:

  { name: 'ref', baseName: '$ref', type: 'string', format: '' },
  { name: 'schema', baseName: '$schema', type: 'string', format: '' },
  { name: '_default', baseName: 'default', type: 'any', format: '' },
  { name: '_enum', baseName: 'enum', type: 'Array<any>', format: '' },