juju upgrade-series doesn't work if the target series isn't available in distro-info on the CLIENT machine
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
High
|
Unassigned |
Bug Description
I've been upgrading an Juju + OpenStack machine from circa 2016 where the machines all started life as Xenial.
The 'main' machine is a Xenial host, running MaaS, and the controller is also running on a Xenial VM.
The controller and model have been upgraded from 2.3.2 -> 2.8.10 (with the intermediary steps).
The client is 2.8.11 on Xenial.
Upon issuing "juju upgrade-series" juju responded as:
$ juju upgrade-series 3/lxd/0 prepare focal
ERROR "focal" is an unsupported series
After many, many hours of checking the controller, images, charms' metadata.yaml on the machine, eventually, it was suggested that distro-info on the CLIENT machine may not have focal info.
Sure enough, it didn't, as the Xenial has been updated in a while.
So I "apt update && apt install distro-info" and focal appeared in the /usr/share/
I then issued the upgrade-series command again, and:
$ juju upgrade-series 3/lxd/0 prepare focal
WARNING: This command will mark machine "3/lxd/0" as being upgraded to series "focal".
This operation cannot be reverted or canceled once started.
Units running on the machine will also be upgraded. These units include:
rabbitmq-server/5
nrpe/43
Leadership for the following applications will be pinned and not
subject to change until the "complete" command is run:
nrpe
rabbitmq-server
Continue [y/N]?
---
So a few observations here:
1. client details of focal in distro-info were required? To series-upgrade a machine on a server in a distant cloud. Obviously, that's a bug.
2. Would it have worked if I was on say, CentOS, a Mac or Arch?
3. The error message is extremely unhelpful. Adding verbosity does nothing to help. There is no indication as to whether this was a charm issue, an image issue, an version issue, etc. More verbose and informative error messages are needed here, please.
Changed in juju: | |
milestone: | none → 2.9.6 |
importance: | Undecided → High |
status: | New → Triaged |
Changed in juju: | |
milestone: | 2.9.6 → 2.9.7 |
Changed in juju: | |
assignee: | nobody → Simon Richardson (simonrichardson) |
Changed in juju: | |
assignee: | Simon Richardson (simonrichardson) → nobody |
milestone: | 2.9-next → 3.0.1 |
Changed in juju: | |
milestone: | 3.0.1 → 3.0.2 |
Changed in juju: | |
milestone: | 3.0.2 → 3.0.3 |
Changed in juju: | |
milestone: | 3.0.3 → 3.0.4 |
So a few observations; I believe we're attempting to fail early, but in order to fail early we need valid up-to-date information. The problem is we don't know if you have the up-to-date information and we don't tell uses of the juju client that they'll require an up-to-date distro-info via apt.
I suspect we can skip the local validation check in the CLI so that the actual check is done server-side.