enable multiarch support in prowjobs

[upodroid]

I introduced a new label called preset-enable-multiarch-support: "true" that we can set on prowjobs that will allow them to tolerate the taint set on the arm64 nodes and run on them sometimes.

The intention is to attach the labels on jobs that don't care about the architecture, such as linting, verify, e2e runner jobs, etc

In the near future, the EKS cluster will also have Graviton(arm64) nodes enabled as well, so we can apply the same strategy there too.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: upodroid

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:

• OWNERS [upodroid]

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

[upodroid]

Test failure is being fixed at https://github.com/kubernetes/test-infra/pull/35530/files#diff-4c91473011b71c39bad67a8fbeef555b3a79182241ddfc6b0257b11fe3d04efa

[ameukam]

I don't think this relevant to the intent of the PR ?
why the switch ?

[upodroid]

It is relevant to this PR. The old image wasn't multi-arch so the lint job that I updated above would fail if it was scheduled on an arm node.

[upodroid]

/retest

[k8s-ci-robot]

PR needs rebase.

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-sigs/prow repository.

[BenTheElder]

I introduced a new label called preset-enable-multiarch-support: "true" that we can set on prowjobs that will allow them to tolerate the taint set on the arm64 nodes and run on them sometimes.

The intention is to attach the labels on jobs that don't care about the architecture, such as linting, verify, e2e runner jobs, etc

This could actually introduce some really surprising failures, the linting jobs do actually typically lint for the host platform, and e2e runner jobs will build for the host platform assuming it is also the target platform.

[BenTheElder]

For example, when we run golangci-lint, we run it for the host architecture, it's impractical to run it for all, and that means we are going to get some different code and behavior because of code restricted by platform.

Randomizing the hosts can make for difficult to debug failures, we don't surface this very well in CI, see previously with the kernel issues and the ipv6 jobs on mid-upgrade nodepool. Most of our contributors will not see what's going on there.

It means the results are less comparable over time, I don't think we should do that with most of our CI.

Something like, launching the cloudbuilds, sure.

But basically anything that builds ... (including linting, it parses for the host platform typically) fuzzing the architecture in between runs is ... a bit chaotic.

cc @kubernetes/sig-testing-leads

[upodroid]

It means the results are less comparable over time, I don't think we should do that with most of our CI.

It will be an opt-in feature and jobs that compile/build artefacts aren't generally not a good fit.

We have many jobs that launch e2e tests on clouds and ideally, they would benefit from this change, specifically the periodic jobs that don't build kubernetes and fetch them the CI buckets.