Comment 4 for bug 2020753

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.