Conversation
Both CI axes are single-family and which one a suite lands on is not fixed, so a test that only makes sense on one of them has no way to tell. ClusterIPFamilies reads a node's podCIDRs and returns the set it finds. First of two commits adding an IPv6-only DNS guard.
kind's DNS translation is IPv4-only: CoreDNS inherits the node's IPv4 resolver, which no pod on an IPv6-only cluster can reach, so nothing resolves and no actor boots. Every suite then goes red at once and not one of them names the cause. A busybox pod now looks up an external AAAA and fails with that diagnosis instead. It skips unless the cluster is IPv6-only, and probes a bare pod rather than an Actor: atenet-egress does not go Ready on IPv6-only, for an unrelated Envoy bind, so an Actor-based assertion would be a standing red.
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
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.
On an IPv6-only kind cluster CoreDNS inherits the node's IPv4 resolver and nothing resolves from inside a pod, so no actor boots and every suite goes red at once without naming the cause.
hack/create-kind-cluster.shrepoints CoreDNS at an IPv6 upstream; this asserts the cluster under test actually got that treatment, and names DNS as the reason when it did not.It replaces the in-script probe removed from agent-substrate#958, and skips unless the cluster is IPv6-only, so it needs an IPv6-only lane (agent-substrate#939) before it executes anywhere. Deliberately a bare pod rather than an Actor:
atenet-egressdoes not go Ready on IPv6-only for an unrelated Envoy bind, which would make an Actor-based assertion a standing red rather than a regression guard.🤖 Generated with Claude Code