Fix conformance metadata release 1.20

[heyste]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

#98940 addressed a SIG-Scheduling conformance test that was relocated to SIG-Network by tagging those changes to be part of the 1.21 release. This PR reverts changes made to the 1.20 release conformance metadata which is causing k8s-conformance tests to fail at the moment.

Which issue(s) this PR fixes:

• Conformance results for v1.20/k0s v0.10.0 cncf/k8s-conformance#1310
• Conformance results for v1.20/openstack-magnum cncf/k8s-conformance#1316

Special notes for your reviewer:

NONE

Does this PR introduce a user-facing change?

Reverting a metadata change that causes failures in tools that test for Kubernetes conformance.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

NONE

[k8s-ci-robot]

@heyste: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[heyste]

/sig architecture

[heyste]

/test pull-kubernetes-node-e2e
flake

 Cloning into 'test-infra'...
fatal: unable to access 'https://github.com/kubernetes/test-infra/': Could not resolve host: github.com 

[heyste]

/area conformance

[heyste]

/sig scheduling

[heyste]

/test pull-kubernetes-integration
flake

dial tcp: i/o timeout writer close error:
Post \\\"https://storage.googleapis.com/upload/storage/v1/b/kubernetes-jenkins/o?alt=json\\u0026name=pr-logs%2Fpull%2F99081%2Fpull-kubernetes-integration%2F1361113427702976512%2Fstarted.json\\u0026prettyPrint=false\\u0026projection=full\\u0026uploadType=multipart\\\": oauth2: cannot fetch token:

Post \\\"https://oauth2.googleapis.com/token\\\": dial tcp: i/o timeout]\",\"file\":\"prow/cmd/initupload/main.go:45\",\"func\":\"main.main\",\"level\":\"fatal\",\"msg\":\"Failed to initialize job\",\"severity\":\"fatal\",\"time\":\"2021-02-15T00:58:40Z\"}\n") Init container place-entrypoint not ready: (state: waiting, reason: "PodInitializing", message: "")

[heyste]

/test pull-kubernetes-e2e-kind
x2 flakes

• Kubernetes e2e suite: [sig-storage] PersistentVolumes-local [Volume type: dir-link] Two pods mounting a local volume one after the other should be able to write from pod1 and read from pod2
• Kubernetes e2e suite: [sig-storage] PersistentVolumes-local [Volume type: dir-link] Two pods mounting a local volume one after the other should be able to write from pod1 and read from pod2

Common error: tests taking to long, timed out waiting / gave up waiting

[heyste]

/test pull-kubernetes-e2e-gce-ubuntu-containerd
flake

Kubernetes e2e suite: [sig-auth] Metadata Concealment should run a check-metadata-concealment job to completion | 15m3s

 test/e2e/auth/metadata_concealment.go:34
 Feb 15 01:19:24.319: failed to ensure job completion (metadata-concealment-614:check-metadata-concealment)
 Unexpected error:
     <*errors.errorString | 0xc000202200>: {
         s: "timed out waiting for the condition",
     }
     timed out waiting for the condition
 occurred 
test/e2e/auth/metadata_concealment.go:63

[heyste]

/test pull-kubernetes-e2e-kind
x2 flakes

• Kubernetes e2e suite: [sig-storage] PersistentVolumes-local [Volume type: dir-link] Two pods mounting a local volume one after the other should be able to write from pod1 and read from pod2
• Kubernetes e2e suite: [sig-storage] PersistentVolumes-local [Volume type: dir-link] Two pods mounting a local volume one after the other should be able to write from pod1 and read from pod2

Common error: tests taking to long, timed out waiting / gave up waiting

[dims]

/test pull-kubernetes-e2e-kind

[ravisantoshgudimetla]

What is the process for making changes to conformance tests? Should we update some other file in sonobuoy so that there is no drift between what sonobuoy expects and what is available in main or release branch of k/k?

[vladimirvivien]

To be clear, this test filter change should not impact Sonobuoy the project itself (as sonobuoy simply passes specified test filter directly to the e2e test binary). However, if Sonobuoy is being used in a build pipeline for conformance with a specified set of filters, this change will impact the use of Sonobouy.

[spiffxp]

/cc

[justaugustus]

cc: @kubernetes/release-engineering

[johnbelamaric]

Couple questions:

1. has this been resolved by updates to the conformance validation process? If so, why would we need to revert this?
2. If we revert it, what problems does it cause for SIG Windows?

[johnbelamaric]

@jsturtevant this is not a new test, it existed in 1.19 as well, what changed? We did fix a specific issue related to this test, where it was previously (in 1.19 and earlier) not checking if the actual ports we wired up correctly. Did that cause issues for Windows?

[jsturtevant]

yes, the updates to do the checks on the ports used hostNetwork which doesn't work on windows: #96627. So we marked it linux only: #97003

I back ported it to 1.20 but maybe there was something missing or should have updated for sonobouy as well?

[jsturtevant]

2\. If we revert it, what problems does it cause for SIG Windows?

As discussed on slack we could exclude it in our 1.20 tests. The updates to in 1.21 (#98299) don't cause issues that I have seen so far

[dims]

@spiffxp @johnbelamaric we need this to merge in time for the next 1.20.x release. The problem is that we are getting reports from folks submitting CNCF conformance reports and the CI there is logging this as a failure. We should also pay attention on merging changes to this yaml going forward in the release branches.

@kubernetes/release-managers

[dims]

/approve
/lgtm

[johnbelamaric]

After discussing with @jsturtevant, SIG windows will deal with skipping this on their own, so we can revert.

/approve

[liggitt]

/approve

[dims]

/release-note-none

[justaugustus]

For RelEng:
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, heyste, johnbelamaric, justaugustus, liggitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• test/conformance/testdata/OWNERS [johnbelamaric]
• test/e2e/scheduling/OWNERS [liggitt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment