fix(test): wait for cluster ready before checking coredns after start - #5546
Merged
Merged
Conversation
test_microk8s_stop_start was flaky because after microk8s.start it immediately checked for coredns processes with no wait. microk8s.start returns as soon as the snap services are started, but coredns (a pod managed by kubelite) takes a few more seconds to be scheduled and run. Fix: call wait_for_installation() after microk8s.start to wait until the node is Ready and all core services have settled before asserting that coredns is running. This is the idiomatic pattern used elsewhere in the test suite. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
louiseschmidtgen
added a commit
to canonical/k8s-dqlite
that referenced
this pull request
Jun 11, 2026
canonical/microk8s#5546 adds wait_for_installation() after microk8s.start, so coredns is guaranteed to be running before the assertion. The flakiness is fixed upstream; no need to tolerate failures here. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
louiseschmidtgen
added a commit
to canonical/k8s-dqlite
that referenced
this pull request
Jun 11, 2026
- join_cluster: call 'microk8s status --wait-ready' after joining so the node is fully registered in the cluster before wait_until_ready is called - get_local_node_status: MicroK8s HA nodes do not get the node-role.kubernetes.io/control-plane label; check whether snap.microk8s.daemon-k8s-dqlite.service is active instead - Restore continue-on-error on stop/start step until canonical/microk8s#5546 merges Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
ktsakalozos-canonical
approved these changes
Jun 26, 2026
louiseschmidtgen
added a commit
to canonical/k8s-dqlite
that referenced
this pull request
Jun 29, 2026
The microk8s flakiness fix (canonical/microk8s#5546) has merged, so the stop/start lifecycle test no longer needs to tolerate failures. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
test_microk8s_stop_startwas intermittently flaky. After callingmicrok8s.start(which returns once snap services are started), it immediately checked for coredns processes with no wait. coredns is a pod scheduled by kubelite — it takes a few extra seconds after the services are up to be scheduled and running.Fix
Add a call to
utils.wait_for_installation()aftermicrok8s.start, before asserting coredns is running. This polls until the node isReady(plus a 30s buffer), which guarantees coredns is scheduled and running. This is the idiomatic pattern already used elsewhere in the test suite.No logic changes — just inserting the existing wait helper at the right point.
Context
Discovered while working on canonical/k8s-dqlite#369, which runs this test suite in CI and had to use
continue-on-error: trueto work around the flakiness.