kubekins/krte: Add main variant

[justaugustus]

• kubekins/krte: Add main variant (part of Changing kubernetes/kubernetes default branch name to main enhancements#2853, cc: @cpanato)

Signed-off-by: Stephen Augustus foo@auggie.dev

/hold for kubernetes/kubernetes#107105
/assign @cpanato @puerco
cc: @kubernetes/release-engineering

[cpanato]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cpanato, justaugustus

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:

• images/kubekins-e2e/OWNERS [justaugustus]

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

[justaugustus]

/test pull-test-infra-unit-test

[BenTheElder]

I missed, have we tested on -experimental at all yet? 1.18 looks like it has some exciting / major changes :D

[justaugustus]

#25723 bumped the golang version to go1.18, so I've updated this to only include the new main variant.
@kubernetes/release-engineering -- Needs /lgtm!

I missed, have we tested on -experimental at all yet? 1.18 looks like it has some exciting / major changes :D

@BenTheElder -- We created the go-canary variant in #18328 to prevent disruption for other experimental jobs when changing Golang major versions.

The experimental variant is used in enough non-SIG Release/Testing, that I've never felt comfortable with subjecting that many jobs to the change.

So right now, if someone is feeling adventurous: use go-canary.
If not, they can use the master variant which doesn't get moved to "next" Golang until it lands in k/k.

That said, we don't really have a policy re: variants.
@kubernetes/sig-testing-leads -- WDYT?

[BenTheElder]

The experimental variant is used in enough non-SIG Release/Testing, that I've never felt comfortable with subjecting that many jobs to the change.

Users opting into -experimental know what they're getting into :-), we've rolled go ahead of k/k in the past here many many times.

IMHO we should be running with new go versions pretty extensively in CI before rolling them to the main repo, that's why -experimental exists (though test-infra now manages go version in repo anyhow ...). Any project choosing to use -experimental is signing up to be experimented on, if that's not suitable for their usage, they need to use another image.

KRTE in particular is more explicitly not even supported for other purposes than testing kubernetes with kind, for this reason (to avoid other usage blocking changes), but "experimental" in the tag should be a pretty good hint + past behavior of regular go upgrades.

I don't think go-canary is used widely enough, and the point of -experimental vs "go-canary" is that it might not only be go that we need to ensure is safe to upgrade, the same CI jobs may also be used to trial e.g. docker upgrades, it's wasteful to have jobs running only intended to be used for go upgrade testing.

At different points in time we have different things to update in the CI environment that should receive the same level of soaking through some e2e canary jobs etc before rolling to main/master / ...

[BenTheElder]

I'm not sure what happened where this go round, but the go1.18 update was extremely not smooth, it doesn't feel like it got soaked in CI ahead of updating.

[BenTheElder]

/lgtm

[liggitt]

if the intent of this is just to enable master/main kubekins tags to be identical, this seems harmless.

I agree we should stop bumping master (and now main) images to a new version of go before demonstrating green runs on the go-canary / experimental image, but that seems outside the scope of this PR.

@justaugustus, is there an issue tracking the fallout of the last CI go bump to 1.18 and how we'll change the rollout for go 1.19?

[justaugustus]

I'm not sure what happened where this go round, but the go1.18 update was extremely not smooth, it doesn't feel like it got soaked in CI ahead of updating.

I agree we should stop bumping master (and now main) images to a new version of go before demonstrating green runs on the go-canary / experimental image, but that seems outside the scope of this PR.

@justaugustus, is there an issue tracking the fallout of the last CI go bump to 1.18 and how we'll change the rollout for go 1.19?

@BenTheElder @liggitt -- I've filed kubernetes/release#2487 for this.

The tl;dr is:

• too many cooks
• we got caught off-guard by the go1.18 official release
• canary presubmits were not run on the PR updating to go1.18 official: golang: Update to 1.18 from 1.18rc1 kubernetes#108870
• we bumped kubekins/krte variants (ref: releng: update kubekins/krte to Go 1.18 #25723) with looking at the canary presubmits

The timing/order of operations for much of this is documented in our golang update issue template, so I think what it came down to here was a few too many folks working on this without following up on the previous steps.

/hold cancel