There are two issues with the built-in kind cluster functionality (that are likely rel

<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clip

Fix kind cluster discovery about kuttl HOT 2 OPEN

kudobuilder commented on June 15, 2024

Fix kind cluster discovery

from kuttl.

Comments (2)

jbarrick-mesosphere commented on June 15, 2024

    kuttl: harness.go:326: run tests finished
    kuttl: harness.go:392: collecting cluster logs to artifacts/kind-logs-1597357528
    kuttl: harness.go:420: skipping cluster tear down
    kuttl: harness.go:421: to connect to the cluster, run: export KUBECONFIG="/home/justin/usr/src/github.com/mesosphere/dispatch/kubeconfig"
--- PASS: kuttl (221.55s)
    --- PASS: kuttl/harness (0.00s)
        --- PASS: kuttl/harness/login (0.51s)
PASS
➜  dispatch git:(dev) ✗ (⎈ kubernetes-admin@konvoy-staging-devx:default) kubectl kuttl test --skip-delete --skip-cluster-delete --config ./test/kuttl-config/kuttl-test-default.yaml --test login
 
=== RUN   kuttl
    kuttl: harness.go:339: starting setup
    kuttl: harness.go:222: running tests with KIND.
    kuttl: harness.go:118: KIND is already running, using existing cluster
    kuttl: harness.go:392: collecting cluster logs to artifacts/kind-logs-1597357631
    kuttl: harness.go:420: skipping cluster tear down
    kuttl: harness.go:421: to connect to the cluster, run: export KUBECONFIG="/home/justin/usr/src/github.com/mesosphere/dispatch/kubeconfig"
    kuttl: harness.go:458: fatal error getting client: stat /tmp/kudo715356934/kubeconfig: no such file or directory
--- FAIL: kuttl (0.62s)
FAIL
➜  dispatch git:(dev) ✗ (⎈ kubernetes-admin@konvoy-staging-devx:default)

from kuttl.

kensipe commented on June 15, 2024

after investigate main code is working as designed... the result is

 harness.go:526: skipping cluster tear down
    harness.go:527: to connect to the cluster, run: export KUBECONFIG="/Users/kensipe/projects/go/src/github.com/kudobuilder/kuttl/kubeconfig"
    harness.go:565: fatal error getting client: KIND is already running, unable to start

code:

		if h.kind.IsRunning() {
			// we don't take over an existing kind cluster for --start-kind
			// which means we do not stop that cluster.  User will either need to switch to existing cluster or stop it.

This seems like an enhancement (perhaps semantics). The request is to use an existing running cluster... which can do if it was previously run by kuttl. kuttl does record a kubeconfig to the CWD after getting the connection (this is generally for context for kubectl commands). We could "fallback" to this configuration when an existing Kind is running.

Still thinking through if this could lead to some confusion... and haven't found an issue.

So..