local_overlay support for charmcraft built charms

[freyes]

Charms that define multiple bases can produce multiple output files with long names (e.g. octavia_ubuntu-20.04_ubuntu-22.04.charm), this makes more time consuming to have the testing bundles right, but also you have to keep them updated as bases get dropped and added to enable new ubuntu series.

It would be nice if the local_overlay flag could programmatically detect what's the right charm for a bundle, it would be necessary to read the series key in the bundle, at the top level and at the application level, e.g:

series: jammy
applications:
  keystone:
    charm: ch:keystone
    series: jammy

^ in this case the overlay generated should look something like this:

applications:
  keystone:
    charm: "../../keystone_ubuntu-22.04-amd64_ubuntu-22.10-amd64.charm

[ajkavanagh]

I like the general direction of this idea, and I'd like to add a suggestion.

Rather than have zaza "guess" which is the right charm, why not change the charm: keyword into something that is explicit about needing to be changed. This would allow multiple charms to be 'overlay-ed' as required.

I'm not sure what the best format would be, but maybe something like: charm: "overlay(charm=keystone, arch=$arch, base_in=22.04)" which would also the overlay bit to be matched, and then the other parts to be matched against various charms available.

I'm suggesting that $arch be 'set' by zaza to amd64 (the default) but in time grow to work against other arches, and that, say, "overlay(charm=keystone, base_in=22.04)" would default to am64.

[freyes]

On Mon, 2022-10-10 at 05:45 -0700, Alex Kavanagh wrote: I like the general direction of this idea, and I'd like to add a suggestion. Rather than have zaza "guess" which is the right charm, why not change the charm: keyword into something that is explicit about needing to be changed. This would allow multiple charms to be 'overlay-ed' as required. I'm not sure what the best format would be, but maybe something like: charm: "overlay(charm=keystone, arch=$arch, base_in=22.04)" which would also the overlay bit to be matched, and then the other parts to be matched against various charms available. I'm suggesting that $arch be 'set' by zaza to amd64 (the default) but in time grow to work against other arches, and that, say, "overlay(charm=keystone, base_in=22.04)" would default to am64.

The base can be read from the bundle (e.g. "series: jammy"), IIRC the distro-info package has (python) code to transform from series codename to it's version. The architecture can be obtained from the juju model, for example in s390x deployments we run "juju set-model-constraints arch=s390x" otherwise juju assumes amd64. About overlaying multiple charms, sounds like a good idea, but I think that's something we need to make in tandem with zosci, an ansible task specifically, for example a task that downloads all the charms that are needed reading the "Depends-On" header and leaving all those *.charm files in a "builds" directory, so zaza can identify all the ones present in that dir and prepare an overlay for them.