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.

[achavan-atl]

Any update here? 1.31 has been released now with a patch update as well, will we see v1 for this package any time soon?

[charankumarpalla]

@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

@brendandburns now that version 0.22.1 is available, would you recommend switching to it instead of the latest release candidate (rc7)? We’re currently on rc6, which has been working well, but we're a bit cautious about any potential changes in v0.22 that could disrupt our existing workflows.

[xkabylgSICKAG]

As an additional data point: we've been using the 1.0 rc for a few months now in our production app without any issues. We mostly interact with the job APIs and watch functionality. We could even remove a bunch of hacky code to fix the broken datetime typings in the old version! 😄

[atamon]

As an additional data point: we've been using the 1.0 rc for a few months now in our production app without any issues. We mostly interact with the job APIs and watch functionality. We could even remove a bunch of hacky code to fix the broken datetime typings in the old version! 😄

Same here, 1.0-rc7 is work well for us! We ran into the issue fixed in https://github.com/kubernetes-client/javascript/pull/1937 last week though, and are looking forward to that being included in a 1.0 release 😄

[cjihrig]

Now that Node v23 is out, it might be worth adding it to the CI before dropping the "rc." The npm downloads by version seem to show good adoption of the v1.x branch (not as much as v0.x, but I think that is expected).

[achavan-atl]

@brendandburns Could I pain you back to this issue to help with a stable release here please 🙇

[CGNonofr]

Can you please release a rc8 with the last v5 protocol update?

[brendandburns]

I think that we are going to align the 1.0.0 release to the Kubernetes 1.32 API which is slated for 12/11.

I will see about cutting an rc8 before then, but no promises given everything else that is going on.

[achavan-atl]

How's the aligned release for 1.0.0 with 1.32 looking? Noted 1.32 hasn't released yet, just want to make sure this release happens

[brendandburns]

@cjihrig @mstruebing

The Kubernetes 1.32 release and generated code has landed. I think we're ready to ship the 1.0.0

wdyt?

[cjihrig]

+1 from me.

[CGNonofr]

+1

[mstruebing]

+1 I'm excited!