Release of v1.0.0

[rossanthony]

I'm curious if anyone is actively working on further enhancements to the release-1.x branch? I'm keen to help get it over the finish line, if there's enough pending work to divide and conquer?

I noticed there are a couple of things mentioned:

• Complexity of middleware use: https://github.com/kubernetes-client/javascript/issues/754#issuecomment-2004562303
• The errors being returned appear to have a body of a string or undefined, and not an object as they were in 0.2.0 - https://github.com/kubernetes-client/javascript/issues/754#issuecomment-2074904937

There's also a snyk vulnerability with the version of the tar package being using in 1.0.0-rc4 and I noticed there are some @types in the dependencies which should be moved to devDependencies: https://github.com/kubernetes-client/javascript/blob/release-1.x/package.json#L57-L63

@brendanburns let me know if there's anything I can do to help? It's hard to know what might be in flight already, so wanted to check first before starting anything and potentially stepping on anyones toes.

[brendandburns]

We're happy to have help here. I know that @mstruebing was working on some things, but nothing too active. Please feel free to send PRs for any of those issues.

Lately the main blocker has been regenerating the client for Kubernetes 1.30

[rossanthony]

Lately the main blocker has been regenerating the client for Kubernetes 1.30

Oh interesting, so there are some breaking changes with the kube API in 1.30?

[brendandburns]

No, for some reason when I regenerate, the code isn't changing, the generation logic is stuck on 1.28.4, it's something in the script somewhere but I haven't had time to figure it out.

[davidgamero]

@rossanthony

For the complexity of middleware use, the current approach relies on reconstructing internals ServerConfiguration as a result of the inability to merge headers at request time into generated API calls as the configuration is replaced with no option to merge

in order to improve our ergonomics of the client, we could create something like a WithHeader(kc, key, value): Configuration utility wrapper to clean up the usage for now which could improve the Patch use case:

const kc = new k8s.KubeConfig();
...
await k8sApi.patchNamespacedPod(
  {
    name: podName,
    namespace: namespace,
    body: patch,
  },
  WithHeader(k8sPatchPodConfiguration, 'Content-Type', 'application/json-patch+json'),
);

Long-term it'd be best to get something upstream into the generator as I doubt we are the only ones who have a need for overriding headers at request time.

I've added an issue on the generator to track what I think would help clean this up: https://github.com/OpenAPITools/openapi-generator/issues/18846

[brendandburns]

I just pushed 1.0.0-rc5 which contains support for Kubernetes 1.29 and some recent fixes.

[charankumarpalla]

@brendandburns any planned date where we can expect 1.0.0 release ..instead of -rc ?

[brendandburns]

@charankumarpalla no current date, is the rc label causing problems for you?

[charankumarpalla]

@charankumarpalla no current date, is the rc label causing problems for you?

No , we were planning to use latest rc version (as we are seriously getting hit with request module vulnerability on older version ) just want to check if this can be integrated with our production grade code 😀

[brendandburns]

@charankumarpalla it's as production ready as it's going to get. If you find bugs, we'll fix them.

The main reason for the rc is that it contains many breaking changes because the code generator is different, so we need mileage on the code to see what works and what doesn't.

We'd love for you to adopt the rc and provide feedback if things work or don't, that helps us move towards a 1.0.0

[mstruebing]

Yeah I second that, the main reason it’s not provided as production yet is because we don’t have much feedback on how much trouble (or not) it will cause. I myself found myself in a situation where I don’t use the product anymore for production work so I can not provide valueable feedback.

Anything in that regard would be very very helpful.

[shmam]

Also chiming in to say that my team is also looking forward to a 1.0.0 release (mostly for the move from requests to fetch). 😄 We are using the 1.0.0-rc6 and are happy to provide any feedback if we encounter issues.

[rossanthony]

@brendandburns I'm curious about the value of the KUBERNETES_BRANCH in the settings file here: https://github.com/kubernetes-client/javascript/blob/release-1.0.0-rc6/settings#L24

Is it important that when using 1.0.0-rc6 our cluster should be running at least v1.30.1 or above?

We've been trying rc6 on a cluster running v1.28.9 and seeing some weirdness with update/create secret calls silently failing. Wondering if we should stick with rc4 for now (which is working fine) until we get our cluster upgraded to v1.30.1+

[brendandburns]

@rossanthony in theory a client generated from 1.30 should work correctly with a 1.28 cluster because of the three version compatibility commitment, especially for apis that are v1, it's possible that v1betaN apis might change/break across those versions. If rc4 works reliably and rc6 doesn't that would be interesting to explore. What specific resources?

[CGNonofr]

Will there be a 1.0.0-rc7, including the 1.30 compatibility using fetch?

[mstruebing]

I guess at this time we could even make it 1.0.0 without an RC-tag. This way it would encourage more people to use it and issues are detected and fixed faster (probably). WDYT @brendandburns?

[brendandburns]

Yeah, I'm ok with releasing a 1.0.0 maybe in conjunction with the generated code for 1.31?

[mstruebing]

Sounds good to me.