No CI testing for the case that cloud-init is installed but not in use
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-advantage-tools (Ubuntu) |
Fix Released
|
Undecided
|
Renan Rodrigo | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned | ||
Lunar |
Fix Released
|
Undecided
|
Unassigned | ||
Mantic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[ Original description ]
[ Impact ]
As discovered in regression bug 1936833, current CI doesn't cover the case that the cloud-init package is installed but not in use. In general, it's acceptable for _any_ package to be installed but not in use, and behaviour should never break because of this. Perhaps this needs adding to your CI test matrix, and or the test plan in https:/
[ Test Plan ]
The change is adding a test itself - running it should validate this bug. The test will be executed as part of the SRU process validation, to address https:/
[ Where problems could occur ]
If the test would implement something wrong and make assumptions on how cloud-init works, we could be relying on something that does not match reality when checking if it does not work. Reviews in the test by cloud-init people helped us ensure this risk is mitigated, making sure the test makes sense.
Changed in ubuntu-advantage-tools (Ubuntu): | |
status: | New → Triaged |
Changed in ubuntu-advantage-tools (Ubuntu): | |
assignee: | nobody → Renan Rodrigo (renanrodrigo) |
tags: | added: sc-1400 |
Changed in ubuntu-advantage-tools (Ubuntu): | |
status: | Triaged → Fix Released |
description: | updated |
Hi Robie, thanks for opening this bug!
We discussed covering the "cloud-init installed but disabled" case yesterday at standup, and it would be indeed good to cover it. The question we also discussed how the failure mode we hit compares to any of the other commands/tools called during postinst (or any other stage) failing in a way we didn't account for. And there is a difference: is that cloud-id was not misbehaving, so this is a valid setup to test, and not just one random way a system can be in a broken state.
This said, cloud-id clould probably behave better when there's no instance-data.json, considering it a valid case of cloud-id being "" (empty string). However this has to be discussed on the cloud-init side and can't be considered a fix on the ua side, given that ua doesn't even depend on cloud-init, so we can't "fix" this on the cloud-init side and declare a versioned dependency.
On your "fix based implementation detail" comment: that was also brought up by Renan, who has a different fix to propose that takes into account the RC of cloud-id.