🐛 Make Kind Cluster Name Configurable for E2E Tests

[kersten]

Description

This PR introduces the KIND_CLUSTER variable in the Makefile, allowing users to specify a custom Kind cluster name when running end-to-end (e2e) tests.

Previously, the Makefile assumed that the Kind cluster was named kind, which limited flexibility for users managing multiple Kind clusters. With this change, the cluster name is configurable, making the e2e test setup more dynamic.

Motivation

• Some users may run multiple Kind clusters simultaneously and need to specify a custom cluster name.
• The previous hardcoded assumption (kind) made it difficult to test in environments with different cluster naming conventions.
• This change improves the developer experience by allowing easy configuration of the cluster name.

Changes

• Introduced the KIND_CLUSTER variable (defaults to kind if not set).
• Updated the Makefile to check for an active cluster using $(KIND_CLUSTER) instead of assuming kind.
• Maintains backward compatibility since the default behavior remains unchanged

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kersten
Once this PR has been reviewed and has the lgtm label, please assign camilamacedo86 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @kersten. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[camilamacedo86]

Then, we would need to create the cluster name
That would mean that this specific cluster must exist to run the tests, so I think we cannot move forward with this one without having a target with a setup for the e2e tests.

[kersten]

Why should we create the cluster? This change simply extracts the hardcoded kind cluster name into a variable, allowing it to be set dynamically.

Our use case: We create separate Kind clusters for each operator to enable isolated testing. However, the current make test-e2e target fails because it only checks for a cluster named kind, rather than the actual cluster we are using (e.g., kind-example-cluster). By making the cluster name configurable, we ensure the e2e tests can run in any Kind cluster we specify.

[camilamacedo86]

If we decide to create a cluster name, we should also have a target for it, like setup-e2e-test, so that we can call it here. That’s the point I’m trying to make. 😊

[kersten]

Sorry, I'm not sure if I got your point. Do you mean something like:

.PHONY: setup-e2e-test
setup-e2e-test: ## Set up a Kind cluster for e2e tests if it does not exist
	@$(KIND) get clusters | grep -q '$(KIND_CLUSTER_NAME)' || { \
		echo "Creating Kind cluster: $(KIND_CLUSTER_NAME)"; \
		$(KIND) create cluster --name $(KIND_CLUSTER_NAME); \
	}

[kersten]

I believe creating a Kind cluster should be outside the scope of this PR. While we agree that having such a target would be valuable for generalizing multiple projects, this PR specifically focuses on making the Kind cluster name configurable.

The current logic implicitly assumes the cluster name is "kind", and this change simply makes that explicit. It remains fully backward compatible since the default cluster name is still set to "kind", ensuring no disruption to existing workflows.

[camilamacedo86]

Hi @kersten,

We cannot modify the targets to force users to use a cluster name that isn't configured by the Makefile targets. If we move forward with it, it will fail when we make test-e2e, right? (indeed it will probably fail in the ci)

While I might think that we're moving in the right direction by introducing a test-e2e-setup target to create the cluster name and then referencing it here, we need to make these changes as part of a dedicated PR. This will allow us to propose the full implementation, validate everything, and ensure it's properly handled before proceeding. we will need to ensure that it is the right direction to change the full scaffolds.

These changes are particularly sensitive (see for example - check the latest comment #4391), so we must approach scaffold modifications carefully. Once merged, any subsequent release could include this change, making it critical to get it right from the start.

So, let’s ensure everything is in place before moving forward.

[kersten]

I see your point now. The default case would work fine, but it would fail if a different cluster name is used. I'll make the necessary changes.

[camilamacedo86]

/ok-to-test

[camilamacedo86]

Could we have just one commit with all changes?
We have a policy that is to ensure that we have a good history and each PR has just one purpose. ( 1 PR one goal/need/fix addressed )