🌱 fix: update kind-load target to ensure that works aligned with controller-operator

[camilamacedo86]

Standardizing this method simplifies workflows and makes the project more contributor-friendly

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 38.23%. Comparing base (dd64145) to head (c9c3807).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #462   +/-   ##
=======================================
  Coverage   38.23%   38.23%           
=======================================
  Files          15       15           
  Lines        1224     1224           
=======================================
  Hits          468      468           
  Misses        706      706           
  Partials       50       50           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[m1kola]

I vaguely remember that we already tried something like this and there were issues with some setups. I think, was either macOS vs Linux setups or Docker vs Podman. Not sure.

• This change ensures that the kind-load target works seamlessly with any local kind cluster created by the developer, without relying on a bingo-provided version of kind.

What did you mean here? Was the intention to use kind from PATH? This change still uses bingo-provided version of kind.

And I'm not sure that we want to do that do that: kind and other dependencies are intentionally managed by with so we have reproducibility across environments.

[camilamacedo86]

I want to use my own local kind installation instead of relying on a version tied to bingo (e.g., /Users/camilam/go/bin/kind-v0.24.0). Contributors should have the flexibility to work with their local environments without unnecessary dependencies.

Forcing a specific kind of version is restrictive, and global dependencies are unnecessary and a pain. It messed up with my local env.

⚠️ I also don’t want to remember or use /Users/camilam/go/bin/kind-v0.24.0 to run any command for kind. It was frustrating to figure out why the image wasn’t loading.

This approach works perfectly on macOS (I use a Mac, and the CI uses Linux, so we are 100% safe here) and matches the implementation used in con-oper, where it’s not a problem.

Why treat it differently here? Standardizing this method simplifies workflows and makes the project more contributor-friendly. Let’s avoid unnecessary friction for contributors.

[m1kola]

This approach works perfectly on macOS (I use a Mac, and the CI uses Linux, so we are 100% safe here) and matches the implementation used in con-oper, where it’s not a problem.

Why treat it differently here? Standardizing this method simplifies workflows and makes the project more contributor-friendly. Let’s avoid unnecessary friction for contributors.

As I said - I vaguely remember us having issues with kind load. But if it is the same approach as in operator-controller - then we should be good because I believe it was sorted in operator-controller. Here is the background I managed to dig out:

• operator-framework/operator-controller@b4c66de
• operator-framework/operator-controller@d813099

I want to use my own local kind installation instead of relying on a version tied to bingo (e.g., /Users/camilam/go/bin/kind-v0.24.0). Contributors should have the flexibility to work with their local environments without unnecessary dependencies.

This change does not achieve that: make still uses bingo versioned kind. Don't hesitate to submit a PR to further address this.

[camilamacedo86]

You are right
I will do a follow up to fix the kind and do not use it from BINGO

[joelanford]

I want to use my own local kind installation instead of relying on a version tied to bingo (e.g., /Users/camilam/go/bin/kind-v0.24.0). Contributors should have the flexibility to work with their local environments without unnecessary dependencies.

I really disagree with this actually. If the repository is setup to seamlessly ensure the necessary build/test dependencies are present on the local system, there is no good reason:

• for a contributor to use alternate versions of the build tools that are specified by the repo
• for maintainers to increase the complexity of the Makefile to support it.

The more options and overrides that are made available in the Makefile, the harder it is to trust the results of any particular CI task.

To the extent that we can use tooling like bingo to provide specific build tool versions, we should enforce those build tool versions for all contributors. It improves consistency and eliminates most of the "well it works on my system" problems.

[m1kola]

I agree with what @joelanford said above and this is what I meant above when I said that we intentionally manage dependencies like this in the repo with bingo (but I now see that I typed some nonsense there).

I decided to leave these points unanswered here so we don't get distracted here from the consistency fix.

@camilamacedo86 could you please submit a PR or create an issue to address this further? Please describe the issues you are facing in as much detail as possible so we can discuss it there. If it is a time consuming PR - we should probably start with an issue describing a potential solution.

[m1kola]

I'm happy to approve this PR, but commit message needs updating: in this commit we still use bingo provided kind version so this is misleading.

Let's update the commit message, merge and address everything else separately.

[camilamacedo86]

HI @m1kola

Thank you for being a good catcher. I changed the message you are right
For now, let's move with working as con-oper
for we unblock #464 and allow me to run it locally
see that as it is now, it fails for me (I executed make run to have the following result):

 $ kubectl get all -n olmv1-system
NAME                                               READY   STATUS             RESTARTS     AGE
pod/catalogd-controller-manager-68544b985f-vwjz9   0/1     CrashLoopBackOff   1 (7s ago)   16s

NAME                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                     AGE
service/catalogd-service   ClusterIP   10.96.212.219   <none>        443/TCP,9443/TCP,7443/TCP   16s

NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/catalogd-controller-manager   0/1     1            0           16s

NAME                                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/catalogd-controller-manager-68544b985f   1         1         0       16s

Then, I will work on a follow-up to remove the KIND from bingo in both projects.

[bentito]

Why replace common call to Kind with specific call to a particular container-runtime?

[m1kola]

@bentito there is currently no support for CONTAINER_RUNTIME variable in Makefile in catalogd. @camilamacedo86 addresses this in #464 which is currently waiting for this PR.