✨ add kubebuilder/tooling and controller setup to use binaries from the project bin (go/v3-alpha)

[camilamacedo86]

Description

• add hack/tooling to setup the binaries in the bin project when the KUBEBUILDER_ASSETS is not setup
• update the quick start to make clear that the current steps to get the binaries still required until the CLI version v2.3.1

Motivation

• provide a solution that allows users run and debug/troubleshooting the tests, that not requires sudo permissions to setup an env to develop the projects, and provide a code easier to maintain and to read.
• Closes : Change default path from /usr/local/kubebuilder/bin/ to something that doesn't require SUDO #1732
• Closes: Unable to debug/troubleshooting tests of projects built with v3/go-alpha plugin  #1892

[camilamacedo86]

Hi @DirectXMan12, @gabbifish, @pwittrock,

We agreed just push bug fixes to v2+. However, it is not a breaking change and would allow v2 plugin projects able to work with the kubebuilder binary if it wasn't installed from a tarball.

So, are you ok with we do this change in the v2+?

[gabbifish]

/approve

I ran make test as well and all your introduced changes look good! :)

[DirectXMan12]

comment inline, plus as was pointed out in the meeting, we should verify the downloaded tarball.

[DirectXMan12]

/hold

re: pointing at "master", we can bcckport the script to a stable version if need-be

[camilamacedo86]

/test pull-kubebuilder-e2e-k8s-1-17-0

[DirectXMan12]

I'd prefer a runnable Go program to a shell script, I think (there's just so many things that can go wrong in a shell script, with a go run invocation orgs can use a custom module proxy to ensure that they're getting what they expect, etc).

That being said, I think I put on one of these scripts that we should probably install to GOBIN, and then symlink the particular version to bin/whatever or something, so we still share versions when appropriate -- having 27 copies of the same binary in ~ is not ok.

If we want that to live in a separate module in controller-runtime, that's fine.

If we want to migrate the kubernetes release branch to controller-runtime, and re-target the cloud build scripts, that's also probably fine (I don't really care strongly either way).

[estroz]

I'd prefer a runnable Go program to a shell script

In general I agree.

That being said, I think I put on one of these scripts that we should probably install to GOBIN, and then symlink the particular version to bin/whatever or something, so we still share versions when appropriate -- having 27 copies of the same binary in ~ is not ok.

The library API could have "desired version" parameters that gets compared to the versions of GOBIN/PATH binaries, and will install any of those binaries locally if its version does not match the desired version.

If we want that to live in a separate module in controller-runtime, that's fine.

I'd prefer that, so there's a canonical way of installing envtest deps.

If we want to migrate the kubernetes release branch to controller-runtime, and re-target the cloud build scripts, that's also probably fine (I don't really care strongly either way).

Ultimately I'd like to do that as well, especially if c-r has the installation library you mentioned above.

[camilamacedo86]

Hi @estroz @DirectXMan12,

With the latest alpha controller-runtime release, we could simplify its solution. See that it was updated/chaged.

Regards the suggestions made by @estroz:

If we want to migrate the kubernetes release branch to controller-runtime, and re-target the cloud build scripts,
If we want that to live in a separate module in controller-runtime

It might make it harder to keep maintained but I am OK with. However, we have. current problems to solve and the suggested approach will take a while to be achieved. In this way, I think that we should do:

1 - Move forward with this solution to solve the current problems in KB
2 - Raise an issue against controller-runtime to starts to generate the binaries from there.
3 - Copy adapted if it is required the tooling done here to controller-runtime (after this PR get merged)
4 - After the next controller-runtime release with the suggestions made then, we can start to use it and change the KB code implementation.

WDYT?

[estroz]

Common install path and library suggestions: kubernetes-sigs/controller-runtime#1234

[k8s-ci-robot]

@camilamacedo86: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[camilamacedo86]

Closing it a favour to kubernetes-sigs/controller-runtime#1234 and kubernetes-sigs/controller-runtime#1300 as discussed in the bug triage meeting.