Update containerd related tests using latest kubekins image

[bsdnet]

Signed-off-by: Roy Yang [email protected]

What happened:

The following tests failed continuously in the past:
https://testgrid.k8s.io/sig-node-containerd#containerd-e2e-gci-1.2
https://testgrid.k8s.io/sig-node-containerd#containerd-node-e2e-1.2
https://testgrid.k8s.io/sig-node-containerd#containerd-node-e2e-features-1.2

What you expected to happen:
They should succeed.

How to reproduce it (as minimally and precisely as possible):
See https://testgrid.k8s.io/sig-node-containerd

Please provide links to example occurrences, if any:
See https://testgrid.k8s.io/sig-node-containerd

Anything else we need to know?:
From the log of https://testgrid.k8s.io/sig-node-containerd#containerd-e2e-gci-1.2, it mentioned that failing to get k8s image 1.3, which is removed from https://github.com/kubernetes/test-infra/blob/master/images/kubekins-e2e/variants.yaml. Also, kubekins container is out of date.

Ideally, we should use the latest stable kubekins image. Also, the reason bumping to 1.15 is that it is using the same golang version with latest containered.

[k8s-ci-robot]

Hi @bsdnet. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[bsdnet]

/assign @yujuhong

[dims]

/ok-to-test

[dims]

/approve
/lgtm
/assign @BenTheElder @spiffxp

[bsdnet]

/test pull-test-infra-bazel

[MHBauer]

should these be updated as part of #17715 ? how does one get into that automated flow?

[bsdnet]

should these be updated as part of #17715 ? how does one get into that automated flow?

That is a good question. I am not sure how other images are updated automatically. From the code reading, this image is special, and it use given verison golang and kubernetes. Recently, 1.3 was removed
from https://github.com/kubernetes/test-infra/blame/master/images/kubekins-e2e/variants.yaml

[spiffxp]

how does one get into that automated flow?

Use an image that gets built and pushed automatically. In this case, use a version of kubekins that lines up with a version of kubernetes that is still built and supported.

According the current documented policy, 1.15 is no longer in support. You'll want to move to 1.16 to keep up. In practice, the aged-out release jobs are kept around for a few weeks to cut a final patch release. Previous release schedules have included a date for when the old jobs would be removed, but I don't see one on the current release schedule (@kubernetes/patch-release-team @onlydole ?)

Longer term, jobs that need a per-release-branch variant should use config-forker annotations to have a job generated when the release-branch is cut

The code that does the bumping is here, fwiw: https://github.com/kubernetes/test-infra/tree/master/experiment/autobumper

[spiffxp]

/approve
All the above said, I'll merge this to unblock, as it's not making things any worse. Please address in followup PR's.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bsdnet, dims, spiffxp

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:

• config/jobs/kubernetes/sig-node/OWNERS [spiffxp]

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

[k8s-ci-robot]

@bsdnet: Updated the job-config configmap in namespace default at cluster default using the following files:

• key containerd.yaml using file config/jobs/kubernetes/sig-node/containerd.yaml

In response to this:

Signed-off-by: Roy Yang [email protected]

What happened:

The following tests failed continuously in the past:
https://testgrid.k8s.io/sig-node-containerd#containerd-e2e-gci-1.2
https://testgrid.k8s.io/sig-node-containerd#containerd-node-e2e-1.2
https://testgrid.k8s.io/sig-node-containerd#containerd-node-e2e-features-1.2

What you expected to happen:
They should succeed.

How to reproduce it (as minimally and precisely as possible):
See https://testgrid.k8s.io/sig-node-containerd

Please provide links to example occurrences, if any:
See https://testgrid.k8s.io/sig-node-containerd

Anything else we need to know?:
From the log of https://testgrid.k8s.io/sig-node-containerd#containerd-e2e-gci-1.2, it mentioned that failing to get k8s image 1.3, which is removed from https://github.com/kubernetes/test-infra/blob/master/images/kubekins-e2e/variants.yaml. Also, kubekins container is out of date.

Ideally, we should use the latest stable kubekins image. Also, the reason bumping to 1.15 is that it is using the same golang version with latest containered.

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.

[onlydole]

Thank you for the heads up, @spiffxp! It looks like the 1.15 removal dates fell off our schedule with our revisions and we’ll get them re-added 👍🏼

[bsdnet]

Thanks @spiffxp for your detailed explanation.

containered 1.2.x(https://github.com/containerd/containerd/releases/tag/v1.2.13) is officially built with golang 1.12.17 . That is why I bump to 1.15, which is the only version using the same golang per
https://github.com/kubernetes/test-infra/blob/master/images/kubekins-e2e/variants.yaml

I will follow up to move to 1.16, and it will be also nice for auto bumper to do that(remove from variant, bump the version.) I will take a look at that too.

[onlydole]

@spiffxp - to follow up on the 1.15 job removal, I synced up with @justaugustus and SIG Release purposely removed the "1.15 job removal" entry from the schedule. The 1.15 jobs don't exactly correlate to any 1.19 workstreams, and previously, the beta.0 branch was a good time to perform that removal.

Now that the branch cut is on RC.0 AND we have an extended cycle, it's a little too late to have that branch around.

TL;DR - @justaugustus will be removing the 1.15 branch jobs as there are some expectations that the config-forker tooling has, so he will need to verify it still works when someone removes branch jobs "earlier" than the tool expects.

Please let me know if that makes sense, or if there are any other questions on that front, and we can address them!