restore-backup does not honour --agent-version
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Invalid
|
Critical
|
Unassigned |
Bug Description
There is strong evidence that the "upgrade in progress" seen after a restore means "--agent-version" is being ignored. This issue relates to bug 1606265 and bug 1605653
Juju CI uses "--agent-version" on bootstrap to ensure the juju under test is being used. This is also the same scenario where enterprise applications like landscape require repeatability. The option is violated by the restore-backup command and possibly the model's config after restore.
We cannot pass --agent-version as an option to restore-backup. We should not need to because the agent version is in backup file's metadata.json. The restore-backup command should be using the found agent-version from the metadata as series is used to ensure the right machine and agent are used.
It is very odd that only the restore tests are seeing bug 1606265. It implies that the agent-version was lost during the restore. Instead of staying on the correct version, the controller looked for another version! This breaks enterprise customers.
This might also explain the EOFs in bug 1605653. After the new agent is brought up, the restore often fails because of EOF. I understand that "EOF" can be a symptom of juju thinking it is upgrading. Juju cannot upgrade during a restore. Upgrades must be disabled unitl the restore is complete.
Lasly, as always with Juju CI tests, we are testing a future version, it is impossible to upgrade, juju is lying that it is upgrading agents.
summary: |
- restore-backup does not honour -agent-version + restore-backup does not honour --agent-version |
description: | updated |
Changed in juju: | |
assignee: | nobody → Tim Penhey (thumper) |
Changed in juju: | |
milestone: | 2.0-rc1 → 2.0-rc2 |
I'm not convinced that this is actually a problem now.