No support for charms with multiple bases

[fnordahl]

Ubuntu Focal ships with Python 3.8, Ubuntu Jammy ships with Python 3.10. For any charm with anything other than the most basic wheelhouse dependencies, building the charm for Python 3.8 and expect it to run on a Python 3.10 system does not really work well.

Charmcraft and charmhub give us the tools to fix this, but the current build model prevents the use of the long awaited functionality.

At present the build target for reactive charms relies on a rename.sh script which renames all *.charm files in the top level charm directory to something the functional test gate can recognize for deployment.

This does not work well for charms that specify multiple bases, for example:

bases:
  - build-on:
      - name: ubuntu
        channel: "20.04"
        architectures:
          - amd64
    run-on:
      - name: ubuntu
        channel: "20.04"
        architectures: [amd64, s390x, ppc64el, arm64]
  - build-on:
      - name: ubuntu
        channel: "22.04"
        architectures:
          - amd64
    run-on:
      - name: ubuntu
        channel: "22.04"
        architectures: [amd64, s390x, ppc64el, arm64]

With the above configuration charmcraft will produce the following files:

my-charm_ubuntu-20.04-amd64-s390x-ppc64el-arm64.charm
my-charm_ubuntu-22.04-amd64-s390x-ppc64el-arm64.charm

We ought to remove the rename.sh script and add support in the CI to make use of the correct charm for the correct target.

Note that a similar issue was filed here: openstack-charmers/release-tools#249

[ajkavanagh]

The rename.sh was a bit of a hack (by me) to 'make things work' for the release via the Zuul CI and then launchpad -> charmhub. I'm not defending it, just that it was a tactical measure at the time.

One issue we have is "which built charm should the CI system test a model with". We'll need to come up with a mechanism within zosci to be able to match the built charm to the model so that the correct charm is supplied. So the scope of this feature becomes a little more complex, as bundles may represent a focal or jammy system, but (apart from the name of the bundle) there's no metadata to make this connection. So there's also some design work to be done around this feature. However, I'm pretty sure that this would be the right way to go, as the present situation is a compromise.