Changes required make a build after update of component-base

[mszadkow]

Why are these changes needed?

Kuberay in v1.3.0 is incompatible with Kueue v.0.10.1 and above, due to:

vendor/github.com/ray-project/kuberay/ray-operator/pkg/features/features.go:40:9: featuregatetesting.SetFeatureGateDuringTest(tb, utilfeature.DefaultFeatureGate, f, value) (no value) used as value
make: *** [build] Error 1

The change comes from the component-base version difference:
Kuberay has k8s.io/component-base v0.29.6
Kueue has k8s.io/component-base v0.32.1
a small but significant change in https://github.com/kubernetes/component-base/blob/264c1fd30132a3b36b7588e50ac54eb0ff75f26a/featuregate/testing/feature_gate.go#L47

Because of this we had to update component-base on Kuberay.

In result:

• go and go-toolchain version was bumped to v1.23 (also in Dockerfiles)
• k8s.io/api, k8s.io/apimachinery and k8s.io/client-go was bumped to v0.32.1
• sigs.k8s.io/controller-runtime was bumped to v1.19.0
• controller-gen was bumped to v0.16.5 as well as generation was migrated to use kube_codegen.sh

Related issue number

Relates to: kubernetes-sigs/kueue#3822

Checks

• [*] I've made sure the tests are passing.
• Testing Strategy
  • Unit tests
  • [*] Manual tests
  • This PR is not tested :(

[mszadkow]

/cc @mimowo @andrewsykim @kevin85421

[mimowo]

LGTM

@andrewsykim @kevin85421 PTAL, this is currently blocking upgrade of KubeRay to 1.3 in Kueue, which is required for the MultiKueue integration (requiring the managedBy field).

I know this is a massive amount of changes, but all of them are due to the new code generation script, which actually simplifies the code generation: https://github.com/ray-project/kuberay/pull/3004/files#diff-791462c57818fbde5da46c5925c2b709d459724d4824513356aea9816167e893R26-R41.

[mimowo]

@mszadkow is there a way to build Kueue on CI using this commit to KubeRay to double check there are no other blockers to bump KubeRay in Kueue?

[mszadkow]

@mszadkow is there a way to build Kueue on CI using this commit to KubeRay to double check there are no other blockers to bump KubeRay in Kueue?

In terms of compatibility now, I have been able to build Kueue with this feature branch version of Kuberay.
To test it I have added basic managedBy tests and they run and pass.
Seems we have no more blockers as of this point

[andrewsykim]

This LGTM, but given it bumps Go version and other deps, it would be great to get another set of eyes on this. @MortalHappiness @kevin85421 can you take a look as well pleas?

[andrewsykim]

Just realized that KubeRay v1.3 is not compatible with Kueue until this is merged. We're just about to cut v1.3 and it seems risky to include all the changes here, specifically the controller-gen bump. @mszadkow are all the changes in this PR required or is there a more minimal version of this that can work? Specifically worried about the bump to controller-gen that is changing the generated CRD yaml

[andrewsykim]

I think I'm missing something here. I was expecting the function signature of featuregatetesting.SetFeatureGateDuringTest(tb, utilfeature.DefaultFeatureGate, f, value) to change here. Why do we need to bump dependencies if this doesn't change?

[mszadkow]

It has changed so we also adapt this wrapped to it.
In 0.29 this give you a cleanup function that you should call with defer, but since 0.31 it sets the cleanup function for you in ginkgo.
The underlying change is also that it detects parallel set to feature flags so this required change in tests

[mimowo]

@mszadkow may know more details but IIRC controller-gen is a transitive dependency of the core k8s, and it was refactored in 1.31 k8s. OTOH we need to align the core k8s version with Kueue to be able to compile.

[andrewsykim]

I think this would be too risky to add into v1.3 at this point.

To resolve kueue compilation issues, we can consider backport to v1.3.1 or wait til v1.4 as a last resort

[kevin85421]

Hi @mszadkow, @owenowenisme noticed that it seems this PR didn't run make generate.

I cloned your fork and ran make generate with a small fix in update-codegen.sh, and the changed files are as follows:

[kevin85421]

Are the changes in this file manual or automatic?

[mszadkow]

Those are manual.
Some tests required a refactoring, e.g. this change was required because it's no longer run in Describe but inside subject node It()

[mszadkow]

/test buildkite/ray-ecosystem-ci-kuberay-ci/test-autoscaler-e2e-nightly-operator

[mszadkow]

I will attempt to reproduce the issue of autoscaler e2e tests locally

[kevin85421]

@mszadkow you can rebase with the master branch after #3100 is merged.

[kevin85421]

#3100 has already been merged.

[mszadkow]

@kevin85421 sure, rebased

[mimowo]

LGTM after the recent changes and rebase.

What we could consider to make the diff smaller is:

• make a small preapratory PR for ray-operator/controllers/ray/rayjob_controller_test.go
• make a small preparatory PR for bumping golang to 1.23

However, this would mean more PRs to cherry-pick for 1.3.1, and it would not reduce the volume of the PR but much %, but raising this for consideration.

@andrewsykim @kevin85421 PTAL.

[kevin85421]

@mszadkow would you mind rebasing with the master branch?

[mszadkow]

thanks for approval @kevin85421, it's rebased now