Juju complains about downgrading a charm when no downgrade requested
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
In Progress
|
Medium
|
Harry Pidcock |
Bug Description
When re-deploying the same bundle just a moment later, juju is complaining:
ERROR cannot deploy bundle: downgrades are not currently supported
This has occurred in complex deployment scenarios for a while but I've been able to narrow it down to two charms:
juju-lint
landscape-client
To recreate, here's a simple bundle:
series: focal
applications:
landscape-
bindings:
? ''
: oam-space
channel: latest/stable
charm: landscape-client
Deploying works without issue:
ubuntu@fce:~$ juju deploy ./test.yaml
Located charm "landscape-client" in charm-hub, channel latest/stable
Executing changes:
- upload charm landscape-client from charm-hub for series focal from channel latest/stable with architecture=amd64
- deploy application landscape-client from charm-hub on focal with latest/stable
Deploy of bundle completed.
ubuntu@fce:~$ juju status
Model Controller Cloud/Region Version SLA Timestamp
downgrade foundations-maas maas_cloud 2.9.37 unsupported 23:59:30Z
App Version Status Scale Charm Channel Rev Exposed Message
landscape-client unknown 0 landscape-client latest/stable 49 no
Immediately re-running the deploy command fails even though the latest/stable channel still has the same revision:
ubuntu@fce:~$ juju deploy ./test.yaml
ERROR cannot deploy bundle: downgrades are not currently supported
ubuntu@fce:~$ juju info landscape-client
name: landscape-client
publisher: Landscape Charmers
summary: The Landscape administration system client
description: |
Landscape is a web-based tool for managing Ubuntu systems. This package
is necessary if you want your machine to be managed in a Landscape
account. This package provides the Landscape client and requires a
Landscape account.
store-url: https:/
charm-id: WsixdI1C4ocYA0e
supports: bionic, focal, jammy
tags: monitoring
subordinate: true
relations:
provides: {}
requires:
ceph-client: ceph-client
container: juju-info
registration: landscape-
channels: |
latest/stable: 49 2022-09-07 (49) 121kB
latest/
latest/beta: 49 2022-09-07 (49) 121kB
latest/edge: 55 2022-11-29 (55) 6MB
I can work-around the issue by hard-coding the current charm revision:
ubuntu@fce:~$ cat overlay.yaml
applications:
landscape-
revision: 49
ubuntu@fce:~$ juju deploy ./test.yaml --overlay overlay.yaml
No changes to apply.
It's not desirable to hard-code the charm revision and we'd prefer if the latest/stable channel worked as expected.
I can recreate a similar scenario with the juju-lint charm.
I'm not sure if this is a bug with charmhub or juju but, at the very least, juju should be reporting which charm it thinks a downgrade is being requested for. When you've got a bundle with 50 applications, figuring out which one (or two) is causing the issue is very time consuming.
Changed in juju: | |
milestone: | none → 2.9.38 |
status: | New → Triaged |
importance: | Undecided → High |
Changed in juju: | |
milestone: | 2.9.38 → 2.9.39 |
Changed in juju: | |
milestone: | 2.9.39 → 2.9.40 |
Changed in juju: | |
milestone: | 2.9.40 → 2.9.41 |
Changed in juju: | |
milestone: | 2.9.41 → 2.9.42 |
Changed in juju: | |
milestone: | 2.9.42 → 2.9.43 |
Changed in juju: | |
milestone: | 2.9.43 → 2.9.44 |
Changed in juju: | |
importance: | High → Medium |
Changed in juju: | |
milestone: | 2.9.44 → 2.9.45 |
Changed in juju: | |
milestone: | 2.9.45 → 2.9.46 |
Another weird thing is that if you deploy that juju-lint charm from the command line and from a bundle you get different revisions. One is revision 10 (command line) and other is revision 9 (bundle), which is even weirder because release 9 does not exist anywhere (juju info does not show it and charmhub web page also does not show it).
This may or may not be related to this problem, but it was found while testing the juju bundle for this bug. (If it is a separate thing, a new bug can be filed).