Charm Build for Multiple Architectures

charm
1

Hi,

I can’t find info, how to build a charm for multiple hardware platforms. I am building charm for Kubernetes, and I want to build it for both amd64 and arm64. How to do that?

Lumir

2

I don’t think there is any such thing as a architechtural charm as a charm is just a zipfile.

3

You can specify that in your charmcraft.yaml:

type: charm
bases:
  - build-on:
      - name: ubuntu
        channel: "20.04"
        architectures: [amd64, arm64]
    run-on:
      - name: ubuntu
        channel: "20.04"
        architectures: [amd64, arm64]
      - name: centos
        channel: "7"
        architectures: [amd64, arm64]
parts:
  charm:
    build-packages: [git]

I’m not sure if this is correct, but we do have this file without the arm64 bits for our charms.

The docs for this file are in Juju | Charmcraft Configuration

4

Thanks. I added the architectures to the charmcraft.yaml, build and tried run deploy, but with error:

charm or bundle at "./etcd-operator_ubuntu-20.04-amd64-arm64.charm" not found

Deploy command:

juju deploy ./etcd-operator_ubuntu-20.04-amd64-arm64.charm

And yes, I am at the right directory :wink:

5

Maybe you need a build-on section for each architecture?

6

For public charms, we intend to let people use Charmhub to build charms on all the architectures, so you don’t have to have your own build farm. This will be exactly the same as the way you can have snapcraft.io build your snaps on all architectures.

7

I’m super confused about this.

A charm wouldn’t know anything about cpu architecture or have I missed out on some feature of juju here I should learn?

8

Originally, we also thought that charms should be architecture-neutral. The old Juju charm store doesn’t have the notion of architecture. And that ends up causing a LOT of problems. For example, as much as we think of Python as language neutral, it is actually very messy inside. Some libraries have compiled components, and some depend on very specific versions of Python. The same is true of almost any language.

Since we wanted to keep letting people use whatever language they want (the operator framework is focused on Python but Juju doesn’t care) we needed to introduce explicit support for architectures into the system.

So the new charmhub store has the idea of architectures. A charm revision can say that it supports multiple architectures, and then it will be served up for all of those architectures. Or you can have separate builds, and separate revisions, for the different architectures.

To be clear, if you have a charm which is genuinely cross-platform (for example a charm written in pure bash that does not bring any binaries with it :wink: ) then that single blob can be published for all architectures, just as it used to be. But if you need to compile binaries and ship them in your charm, then the new charmcraft tooling supports that cleanly.

And in the near future you will be able to ask Charmhub to build those for you, just as you can with snaps.

2 Likes
9

This makes sense and with that explanation also helps me understand when I should use it.