Build ppc64le image

[mtarsel]

What would you like to be added:
See [1] - there is now a strong need for a kind cluster to work on ppc64le.

Why is this needed:
The Kind node image is needed to test Calico on ppc64le - specifically the e2e tests for Calico.

The kind binary still builds on ppc64le and there are ppc64le machines available via Oregon State University Open Source Lab (OSU OSL) [2]. I can help with the multi-arch development to enable the kind ppc64le image. I can also assist with setting up the machine at OSU OSL. Thanks!

[1] #2707
[2] https://osuosl.org/services/powerdev/

[BenTheElder]

See [1] - there is now a strong need for a kind cluster to work on ppc64le.

According to who? The link doesn't have any comments in the past year.

We've seen almost no demand for this.

On the other hand we have had a LOT of problems with PPC64LE builds being slow, flaky and Kubernetes having no PPC64LE testing.

Frankly I don't think Kubernetes should continue to support untested platforms and kind is only the tip of the iceberg.

The Kind node image is needed to test Calico on ppc64le - specifically the e2e tests for Calico.

I see. You could build your own with some effort.

The kind binary still builds on ppc64le and there are ppc64le machines available via Oregon State University Open Source Lab (OSU OSL) [2]. I can help with the multi-arch development to enable the kind ppc64le image. I can also assist with setting up the machine at OSU OSL. Thanks!

Appreciate the offer but we don't use one-off externally setup infra because the Kubernetes project has a long history with this, inevitably our point of contact with that organization moves on and then we're left with infra:

• of unknown cost and limits
• that nobody has access to maintain
• that nobody currently available knows how was setup
• that we don't have a plan to replace

Instead we only use infra either

• 1. built into github
• 2. dockerhub (though this is considered a legacy decision and we're discussing the trade-offs to migrate off, it does at least have a team with access and we understand the limits of the OSS program, it's not ideal)
• 3. preferred: owned by SIG k8s infra with resources committed to the CNCF that the CNCF has access to and then SIG k8s infra and then the specific project, with documented infra setup (in https://github.com/kubernetes/k8s.io), owned and maintained by the project at large.

I know IBM and other organizations are aware of SIG K8s Infra but we do not have testing for this platform anywhere in Kubernetes. Kubernetes only publishes builds for it by legacy. If someone asked to introduce a platform with no e2e testing (and NOT just kind, which cannot cover all of the node / kubelet tests) today, SIG Release definitely would not accept it.