Comment 4 for bug 2020753

Revision history for this message
John A Meinel (jameinel) wrote :

just like you can deploy a charm by revision, you can also deploy resources by revision. (IIRC, juju deploy mysql-router-k8s --revision 24 --resource mysql-router-image=10
note that I don't know what revisions of the mysql-router-image are available)

There are existing issues against charmhub that it doesn't match a given charm revision with its resources (if you try to deploy revision 20 of the charm but target the channel 8.0/edge it will grab the latest resources from 8.0/edge and not the resources that 'came with' the charm when it was at revision 20).

AFAIK, there is no way to disable a revision that has been exposed publicly in the past. (if you pushed a revision 10 to the store, but never published it, then it won't be accessible, but if you have published 10, then someone can always ask for --revision 10 in the future.)

That would be more on the Store, than on Juju if we wanted to provide that sort of close-and-fully-remove.

As for Joe's comment, according to Alex we already do that:
 juju deploy mysql-router-k8s --revision 24 --trust --channel latest/edge # fail

The issue is that we support any revision that the store exposes, but the store doesn't align the resources with the revision. Either way I'm pretty sure this is still a snapstore server bug, not a bug in juju.