automated charm builds do not automatically associate oci-image resources when releasing

[Jon Seager]

I've been experimenting with the automated charm build system today. I was interested to see how it handled the association of oci-images with release.

Taking the build: https://launchpad.net/~jnsgruk/jnsgruk-charm-kubernetes-dashboard/+charm/jnsgruk-kubernetes-dashboard/+build/57

This successfully built the charm, and released it to 'latest/edge', but the release did not have any oci-image resources associated with it. Due to the charm in question being for Kubernetes, this made the charm un-deployable.

Given that charm releases and oci-image resources have separate revisions, and likely release cycles, might it be sensible to attach the latest revision of each resource to any automated releases until we have a mechanism to be more specific when requesting builds?

For reference, once the charm build above succeeded, I was able to fix the 'latest/edge' channel by re-releasing with resources attached:

charmcraft release jnsgruk-kubernetes-dashboard --resource scraper-image:1 --resource=dashboard-image:1 --channel=edge --revision=9

[Colin Watson (cjwatson)]

I'm a little wary about having to call out to Charmhub for this, and we'd have to be careful about edge cases such as when the set of resources attached to a charm changes, but it sounds like this may be the simplest option for now.

[Colin Watson (cjwatson)]

Brief notes from today's meeting:

 * Rather than having Launchpad work out how to mutate the (charm revision, resource revisions) tuple, the store will be changed to do this automatically when releasing new revisions. William says that this was always planned but not yet implemented. This shouldn't end up requiring any changes to Launchpad.
 * Somewhat relatedly, it would be useful to have the charm build request end up in charm metadata in a similar way that it does for charms. Facundo says that the Starcraft team would prefer this to be consistent between snaps and charms, so they'll add something along the lines of the `SNAPCRAFT_IMAGE_INFO` environment variable used for snaps; once that exists, Launchpad will set it and the store will ingest it.

[Felipe Reyes (freyes)]

I would like to make the OpenStack Engineering team's case here, since we have been finding this issue often enough.

The vast majority of the charms this teahm delivers[0] have defined at leas one resource, 99% of those are 0-bytes files[1], since those resources are optional.

Every release (6-month cadence synced with Ubuntu and OpenStack upstream) we add new bases and create a new tracks

Recently we switched some charms to 'binary charms' where the python wheels are built from source, for example:

- before - https://opendev.org/openstack/charm-nova-cloud-controller/src/branch/master/charmcraft.yaml#L25

- After (binary built charms) - https://opendev.org/openstack/charm-cinder-lvm/src/branch/master/charmcraft.yaml#L31

The problem comes when a new charm is built and tries to get released by Launchpad and the combination of track/risk, base, architecture and base has never been released with a resource before, we get this kind of emails[2]:

```
Launchpad asked Charmhub to release this charm, but it failed:

  Resource 'core18' doesn't have a released revision on channel: xena/stable for charm with id 'QdpjbYn3c9c1GhemNxpUA3SMdokvXeqm' and revision 72
Resource 'octavia-diskimage-retrofit' doesn't have a released revision on channel: xena/stable for charm with id 'QdpjbYn3c9c1GhemNxpUA3SMdokvXeqm' and revision 72
Resource 'snapd' doesn't have a released revision on channel: xena/stable for charm with id 'QdpjbYn3c9c1GhemNxpUA3SMdokvXeqm' and revision 72
```

[0] https://github.com/openstack-charmers/release-tools/tree/master/lp-builder-config
[1] Recently the ceph-mon charm added a new resource called "alert-rules" which contains the rules that are pushed to prometheus alertmanager - https://opendev.org/openstack/charm-ceph-mon/src/branch/master/files/prometheus_alert_rules/prometheus_alerts.yml.default
[2] https://launchpad.net/~openstack-charmers/charm-octavia-diskimage-retrofit/+charm/charm-octavia-diskimage-retrofit.stable-xena.xena/+build/3812

[Daniel Manrique (roadmr)]

Hi, we recently released a "fix" which automatically associates an existing resource when you release a charm that requires it without specifying it.

We take the channel and architecture into account because that's the best way to ensure the resource has a good chance of working with the charm; we obviously can't associate a resource that was released for a different architecture, and since charm requirements for resources can change across channels, we also need to account for that.

This means that a manual release with an explicitly-associated resource will always be required for each channel/architecture combination. After that first release, subsequent ones for that channel/architecture will get that resource if a different one is not specified at release time.

We will not remove the requirement to do a first release per channel/architecture for the reasons explained above; we cannot relax the "filter" because that would (and has, this is why we implemented it this way :) ) result in mismatched or unexpected resource associations with a charm release.