The Charmhub UI doesn't let us filter by ARM64, so it's just showing the most recent for each base.
My guess is that explicitly choosing a revision upon the initial install faithfully satisfies the input, without constraining the deployment architecture. We end up provisioning what is available and the charm happens to work there.
Once deployed, subsequent refreshes constrain the Charmhub request with the deployed arch.
I suspect what we should be doing is constraining the arch based on the deployment revision and failing when it can't be satisfied, but this may not be possible the way events are currently sequenced.
The Charmhub UI doesn't let us filter by ARM64, so it's just showing the most recent for each base.
My guess is that explicitly choosing a revision upon the initial install faithfully satisfies the input, without constraining the deployment architecture. We end up provisioning what is available and the charm happens to work there.
Once deployed, subsequent refreshes constrain the Charmhub request with the deployed arch.
I suspect what we should be doing is constraining the arch based on the deployment revision and failing when it can't be satisfied, but this may not be possible the way events are currently sequenced.
Heather, can you confirm/deny this?