deploy by revision, fails to validate architecture

[Simon Fels]

I have a blank model on a Juju 2.9.44 LXD based controller on an arm64 machine and I deploy the grafana charm at a specific revision:

$ juju deploy grafana --channel=stable --revision=66

The deploy works and the charm is deployed as expected:

$ juju status
Model Controller Cloud/Region Version SLA Timestamp
foo appliance appliance/default 2.9.42 unsupported 13:42:28Z

App Version Status Scale Charm Channel Rev Exposed Message
grafana active 1 grafana stable 66 no Ready

Unit Workload Agent Machine Public address Ports Message
grafana/0* active idle 0 240.6.0.23 3000/tcp Ready

Machine State Address Inst id Series AZ Message
0 started 240.6.0.23 juju-401313-0 focal Running

When I now want to refresh the charm (there is no newer revision available), something weird happens:

$ juju upgrade-charm grafana
Added charm-hub charm "grafana", revision 51 in channel stable, to the model
ERROR cannot downgrade from v2 charm format to v1

Why does Juju find that revision 51 is latest? Looking at the charm on Charmhub (https://charmhub.io/grafana) I see that revision 66 is latest in stable for all architectures.

Revision 51 is most likely a charm build with older metadata, so the format error is not an issue.

This has been recently working and initial found on a 2.9.42 controller. Interestingly this has worked without issue until recently (not sure when), so I doubt it's a Juju issue.

[Heather Lanigan (hmlanigan)]

$ 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: ↑

[Ian Booth (wallyworld)]

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.

[Joseph Phillips (manadart)]

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?

[Heather Lanigan (hmlanigan)]

@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.