Charm store does not associate charm revisions with resource revisions

[Cynerva]

If you deploy a charm by revision, sometimes you get newer resources than you expect, and this causes problems.

For example, we recently hit an issue where deploying cs:~containers/flannel-339 resulted in a broken deployment because it pulled in a newer resource that no longer worked with the charm code. This charm revision had never been released to stable, so deploying it would always pull in resources from edge. This became a big problem when flannel-339 was referenced by bundles (canonical-kubernetes, kubernetes-core) that did get released to stable. Several users encountered this: issue, issue, issue.

In general, this issue also makes it difficult to deploy old revisions of charms (which is useful for testing purposes) since you also need to know and specify the resource revisions that went with them. There's no indication to the user that they have to do this. Here's an example where I had to tell a user why they weren't getting what they expected, and how to work around it: issue.

Our team is finding ways to work around this, but we find ourselves taking on a lot of responsibilities that we would not have to if the charm store kept track of which resource revisions went with each charm revision. We've started adding resource revisions to bundles when we build them (PR), though there is more work ahead of us as we've found there are still charm store clients that don't respect this (issue, issue). We don't have any way to resolve this for users who deploy charms directly; all we can do is point them at the bundle.

It would be nice if us charm and bundle authors, and our users, did not have to do so much work to keep charms and their resources aligned.

[rogpeppe]

@mitechie Perhaps you could explain the rationale for the current design here, please?

[mitechie]

The only design decision is that if you publish a new version of a charm we don't require you to pull back and specify the latest revision of the resources during the publish command of an updated charm. Given that "This charm revision had never been released to stable" I don't believe the design is at issue here.

I agree that when we assume and fill in "default" values for any charm/resource it should only be of published revisions.

[rogpeppe]

Given that "This charm revision had never been released to stable" I don't believe the design is at issue here.

Even if the charm had been released to stable, wouldn't the same issues still apply?