Add support for arm64 arch in che container builds

[nickboldt]

Is your task related to a problem? Please describe

Today, we have builds that use docker buildx to create containers for the following arches:

• che-code: amd64 
• che-dashboard: amd64, arm64
• che-devfile-registry: amd64 
• che-docs: amd64 
• che-e2e: amd64 
• kubernetes-image-puller: amd64
• che-machine-exec: amd64, arm64
• che-operator: amd64
• che-plugin-registry: amd64 
• configbump: amd64, arm64
• developer-images (UDI): amd64 

We also have other builds that are simple single arch:

• devworkspace-operator
• che-server
• che-theia

And we have chectl, which is built for many arches, including Mac and Windows:

• chectl: linux-arm,linux-x64,linux-s390x,linux-ppc64le,darwin-x64,darwin-arm64,win32-x64,win32-x86

Plan after discussions with @l0rd:

• remove ppc64le and s390x [easy] - see Set set provenance:false in workflows with docker/build-push-action (remove 0.9.1 pin in use docker/setup-buildx-action) #21954 and Remove s390x/ppc64le arches in che container builds #21969

• keep arm64 [super easy!]

• add more arm64 builds for the containers that are only single-arch x64 today [potentially lots of work]:

  • che-code
  • plugin registry
  • devfile registry
  • UDI
  • imagepuller + operator
  • che operator
  • server [doesn't use buildx]
  • DWO [doesn't use buildx]

Additional context

Question also sent to https://www.eclipse.org/lists/che-dev/msg04456.html for consideration.

See also:

• Set set provenance:false in workflows with docker/build-push-action (remove 0.9.1 pin in use docker/setup-buildx-action) #21954 and
• Remove s390x/ppc64le arches in che container builds #21969

[sgandon]

I guess my issue is related to this, I try to install Eclipse Che on my mac M1 arm chip and it fails because the Che-operator image does not have the arm64 flavour.

 Deploy Eclipse Che operator
    ✔ Install Dev Workspace operator
      ✔ Create Namespace devworkspace-controller...[Created]
      ✔ Create Dev Workspace operator resources...[Created]
      ✔ Wait for Dev Workspace operator ready...[OK]
    ✔ Create ServiceAccount che-operator...[Created]
    ✔ Create RBAC
      ✔ Create Role che-operator-leader-election...[Created]
      ✔ Create Role che-operator...[Created]
      ✔ Create RoleBinding che-operator-leader-election...[Created]
      ✔ Create RoleBinding che-operator...[Created]
      ✔ Create RoleBinding eclipse-che-che-operator...[Created]
      ✔ Create RoleBinding eclipse-che-che-operator...[Created]
    ✔ Wait for Cert Manager pods ready...[OK]
    ✔ Create Certificate che-operator-serving-cert...[Created]
    ✔ Create Issuer che-operator-selfsigned-issuer...[Created]
    ✔ Create Service che-operator-service...[Created]
    ✔ Create CRD checlusters.org.eclipse.che...[Created]
    ✔ Waiting...[OK]
    ✔ Create Deployment che-operator...[Created]
    ❯ Eclipse Che Operator pod bootstrap
      ✔ Scheduling...[OK]
      ✖ Downloading images
        → Failed to download image, reason: ErrImagePull, message: rpc error: code = NotFound desc = failed to pull and unpack image "quay.io/eclipse/che-operator:7.60.1": no match for platform in manifest: not f
…
        Starting
      Create ValidatingWebhookConfiguration org.eclipse.che
      Create MutatingWebhookConfiguration org.eclipse.che
      Create CheCluster Custom Resource
    Error: Command server:deploy failed with the error: Failed to download image, reason: ErrImagePull, message: rpc error: code = NotFound desc = failed to pull and unpack image
    "quay.io/eclipse/che-operator:7.60.1": no match for platform in manifest: not found.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[SDAdham]

Hello @nickboldt , any progress on this please? almost a week of investigation, it seems that this is a blocker for #23103

[nickboldt]

I'm no longer an active contributor to the Che team, or downstream RH OS Dev Spaces team.

If you'd like to contribute aarch64/arm64 builds, please don't hesitate to do so. AFAIU Che is only supported on amd64 hosts, while Dev Spaces can be run on amd64, s390x, and ppc64le hosts.

cc: @ibuziuk

[AObuchow]

FWIW: We implemented arm64 upstream builds of DWO in devfile/devworkspace-operator#1212.

@SDAdham for #23103, maybe we could start with trying to build CheCode for arm64? Since that's where you're encountering an issue when trying to deploy a workspace.

[SDAdham]

I'm not familiar or experienced enough around Che's architecture. I saw things related to Java and other languages. That's going to be beyond my scope of focus at the moment. I think I'll just give Che a miss... Thanks everyone for the great help. 👍

[nickboldt]

Che (and Dev Spaces) is basically just VSCode or IntelliJ running in a cluster environment so you can preconfigure a development env (including runtimes / build requirements) from a declarative yaml file (devfile). This lets you reuse a project config across multiple developers, so that the "works on my machine" problem goes away and onboarding a new developer can be done in minutes instead of days.

Learn more at https://developers.redhat.com/products/openshift-dev-spaces/overview
Try it free at https://developers.redhat.com/developer-sandbox

You don't need to know the architecture to benefit from it, as long as you're an existing VS Code user...