Found twice: by the batch-2 merge (4 of 6,484 cases red in CyberCloud.Providers.Network.Cluster.Conformance, green when run alone) and by the #30 merge resolution on 2026-09-18 (failed 4 then failed 1 on consecutive runs of the same tree), each time the same test — ClusterConformanceTests.ARealNamespaceHoldsWhatKubernetesPutsThereAndTheReclaimSeesIt — across the family's types.
Why: the test's non-refusal arm asserts that the case's namespace holds a significant object so a reclaim must refuse. Every kind the Network family renders (Kube-OVN's Vpc, Subnet, SecurityGroup, OvnEip, OvnSnatRule) is cluster-scoped — nothing of theirs is ever in the namespace — so that arm cannot be satisfied for this family, and the test passes only when the other arm fires first: the metrics-server discovery refusal on a k3s that is still settling. Whether it passes is a race between the API server's aggregated discovery coming up and the test reaching the assertion. The shifting failure set (4, then 1, then 0) is that race.
What closes it: the shared test needs a third arm for a family whose rendered kinds are all cluster-scoped — assert that the reclaim sees the cluster-scoped objects the case owns (by the ADR-013 labels) rather than a namespaced one, or skip loudly naming the reason, as the other clusterless/cluster-scoped branches of the shared suite do. And the metrics-server refusal arm should not be reachable at all: the k3s recipe disables metrics-server, so a discovery refusal there is the fixture not waiting for aggregated discovery, which is a separate wait to add.
Related: #2 (the k3s recipe), #91 (the harness validates kinds against real definitions now, so it knows which are cluster-scoped), #31.
Found twice: by the batch-2 merge (4 of 6,484 cases red in
CyberCloud.Providers.Network.Cluster.Conformance, green when run alone) and by the #30 merge resolution on 2026-09-18 (failed 4thenfailed 1on consecutive runs of the same tree), each time the same test —ClusterConformanceTests.ARealNamespaceHoldsWhatKubernetesPutsThereAndTheReclaimSeesIt— across the family's types.Why: the test's non-refusal arm asserts that the case's namespace holds a significant object so a reclaim must refuse. Every kind the Network family renders (Kube-OVN's
Vpc,Subnet,SecurityGroup,OvnEip,OvnSnatRule) is cluster-scoped — nothing of theirs is ever in the namespace — so that arm cannot be satisfied for this family, and the test passes only when the other arm fires first: the metrics-server discovery refusal on a k3s that is still settling. Whether it passes is a race between the API server's aggregated discovery coming up and the test reaching the assertion. The shifting failure set (4, then 1, then 0) is that race.What closes it: the shared test needs a third arm for a family whose rendered kinds are all cluster-scoped — assert that the reclaim sees the cluster-scoped objects the case owns (by the ADR-013 labels) rather than a namespaced one, or skip loudly naming the reason, as the other clusterless/cluster-scoped branches of the shared suite do. And the metrics-server refusal arm should not be reachable at all: the k3s recipe disables metrics-server, so a discovery refusal there is the fixture not waiting for aggregated discovery, which is a separate wait to add.
Related: #2 (the k3s recipe), #91 (the harness validates kinds against real definitions now, so it knows which are cluster-scoped), #31.