deploy by revision, fails to validate architecture

$ juju info grafana --arch arm64
name: grafana
...
channels: |
  latest/stable: 51 2021-10-18 (51) 7MB ubuntu@20.04, ubuntu@18.04, ubuntu@16.04
  latest/candidate: 51 2021-10-18 (51) 7MB ubuntu@20.04, ubuntu@18.04, ubuntu@16.04
  latest/beta: ↑
  latest/edge: ↑

Looks like the initial deploy (rev 66) was an amd64 charm.

juju info grafana --arch amd64
name: grafana
publisher: Llama (LMA) Charmers
summary: Graph and Dashboard builder
description: |
  Grafana is the leading graph and dashboard builder for visualizing
  time series metrics.
store-url: https://charmhub.io/grafana
charm-id: Pq1zh5tthkZYkQAh2cK8pkABs3eBJkgo
supports: ubuntu@20.04
tags: monitoring
subordinate: false
relations:
  provides:
    nrpe-external-master: nrpe-external-master
    website: http
  requires:
    application-dashboard: register-application
    certificates: tls-certificates
    dashboards: grafana-dashboard
    grafana-source: grafana-source
channels: |
  latest/stable: 23.01-3-g2d08546 2023-02-24 (66) 9MB ubuntu@20.04
  latest/candidate: 23.01-3-g2d08546 2023-02-22 (66) 9MB ubuntu@20.04
  latest/beta: ↑
  latest/edge: 23.04-2-g0bef1f4 2023-04-25 (67) 11MB ubuntu@20.04

But the refresh must be passing in arm64 as the arch, hence it finds revision 51.
I'm confused as to why juju is using arm64 when doing a refresh when the initial deploy was for a revision which was an amd64 charm.

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?

@manadart

When juju queries charm hub for list of bases in general, an architecture is required. However when you ask for a charm revision, it's implied that you know what base (os/version/arch) you are getting, however juju does not validate that.

curl -s https://api.snapcraft.io/v2/charms/refresh -H 'Content-type: application/json' -d '{"context":[],"actions":[{"action":"install","instance-key":"0c13a624-1b03-485c-860f-38dad01566fe","name":"grafana","revision":66,"base":null}],"fields":["bases","config-yaml","download","id","license","metadata-yaml","name","publisher","resources","revision","summary","type","version"]}' | jq .
...
      "charm": {
        "bases": [
          {
            "architecture": "amd64",
            "channel": "20.04",
            "name": "ubuntu"
          }
        ],
...

Juju didn't validate the actual architecture of LXD vs the architecture specified with revision 66, I'd guess and deployed anyways. However the saved base had the actual juju machine architecture, thus refresh found the correct revision of 51 based on a base of arm64/ubuntu/20.04.

The refresh request is correct per juju/charmhub. The initial deploy should have been failed.

The Charmhub API really isn't designed for deploy by revision.