Kubernetes 1.20.4 restores conformance test metadata

Changing the name of a test can break the systems that consume its results even when the behavior under test remains unchanged. Kubernetes 1.20.4 repairs that problem in conformance metadata for a scheduling test involving host ports. The release restores the test's earlier identity within the 1.20 branch after a change intended for the following minor release affected conformance tooling.

The 1.20.4 release was published on 18 February. Its comparison with 1.20.3 is unusually small. Apart from release and changelog work, the changes revert edits to a conformance inventory and its associated test declaration. This is a maintenance release whose practical subject is the reliability of evidence about Kubernetes compatibility.

I care about the API machinery because it lets Kubernetes support controllers beyond its built-in workload types. That extensibility makes a stable account of supported behavior especially valuable. Conformance tooling needs to distinguish an implementation that fails a required behavior from a report whose test names no longer match the expected inventory.

A test name carries information between tools

The repair in pull request 99081 explains the immediate problem. A SIG Scheduling conformance test was being relocated to SIG Network, with those changes assigned to the 1.21 release. Changes to the 1.20 conformance metadata nevertheless caused failures in tools that test Kubernetes conformance.

The patch reverts two earlier commits. One restores the entry in test/conformance/testdata/conformance.yaml. The other restores the corresponding declaration in test/e2e/scheduling/predicates.go. Both remove a newly added [LinuxOnly] marker from the test's identifying text.

The test checks scheduling behavior for Pods that request the same host port while differing in host IP or protocol. Its description says those Pods must be able to schedule to the same node. The restored inventory entry identifies the test as originating in v1.16, which makes this a correction to the representation of an established test within the maintenance branch.

A test inventory and an executable test declaration are related records. The inventory names the behavior that conformance tooling expects to find. The test declaration produces the name associated with an actual run. A change to either can affect the relationship between expected tests and observed results, even without a scheduler implementation change.

That is why calling this a naming cleanup understates the consequence. The name participates in a workflow outside the function containing the assertions. Once another tool uses that name to recognize a required test, changing it alters the information exchanged between the tools.

The patch changes classification, not scheduling logic

The code comparison is useful because it limits what can reasonably be claimed about this release. Its test body remains in place. Scheduler implementation changes are not part of this correction. The patch restores the conformance declaration and removes explanatory text associated with the previous metadata change.

The removed text had explained the Linux-only classification by referring to Windows host networking. Reverting that annotation in 1.20 does not establish a new Windows networking capability. It restores the branch's prior conformance metadata while the relocation proceeds in the minor-release work identified by the pull request.

This distinction prevents a misleading reading of the release. A reader could see the host-port test and infer that 1.20.4 changes port allocation or fixes a scheduling conflict. The actual patch provides no basis for that inference. Its stated purpose is to stop conformance tooling from failing because of the metadata change.

The same discipline applies to the changelog update included between the tags. Much of that file's diff records 1.20.3. Those entries describe the previous patch release and should not be reassigned to 1.20.4 simply because the documentation changed in this comparison. Release documentation and implementation changes need to be read together.

Maintenance includes the consumers of test results

A stable maintenance branch has users beyond cluster operators submitting workload manifests. Distribution builders and conformance tools consume release artifacts and test metadata. Their dependencies can be textual, so a change that looks harmless to the compiler can still break their interpretation of a test run.

The repair takes a conservative approach. It returns the affected branch to the earlier representation instead of requiring every consumer to reinterpret the new marker immediately. The pull request links the conformance repository work that exposed the mismatch, making the effect on downstream tooling explicit.

My preference is for compatibility fixes whose scope can be read directly from the patch. Here that scope is unusually clear. Two reverts restore agreement around the identity of one conformance test, and the release comparison makes it possible to separate those reverts from documentation for earlier fixes.

For a cluster already running 1.20.3, this release should therefore be understood in terms of conformance metadata. For a consumer of conformance results, the restored declaration has a direct purpose. It lets the maintenance branch present the established host-port scheduling test under its expected identity while the planned test relocation remains associated with the next minor release.