New CloudStack DS_MAYBE result causing inadvertent cloud-init runs
| Affects | Status | Importance | Assigned to | Milestone | ||
|---|---|---|---|---|---|---|
| cloud-init (Ubuntu) | Status tracked in Mantic | |||||
| Focal |
New
|
Critical
|
Unassigned | |||
| Jammy |
New
|
Critical
|
Unassigned | |||
| Lunar |
New
|
Critical
|
Unassigned | |||
| Mantic |
Fix Committed
|
Critical
|
Unassigned | |||
Bug Description
=== Begin SRU Template ===
[Impact]
In 23.3, ds-identify automatically returns CloudStack to be DS_MAYBE on VMWare and Xen instances. On instances running on VMWare and Xen that have never identified a datasource, this causes cloud-init to run for the first time where it would have otherwise been disabled.
The fix is to revert https:/
[Test Case]
* Create a VMWare instance that will be detected as DataSourceNone
* Verify that the instance does not attempt to detect the CloudStack datasource
[Regression Potential]
This will cause problems for anybody already using the new behavior. Otherwise, since this is a revert of a commit adding new behavior, I don't see any other regression potential.
[Other info]
Upstream bug: https:/
| Changed in cloud-init (Ubuntu Mantic): | |
| importance: | Undecided → Critical |
| Changed in cloud-init (Ubuntu Lunar): | |
| importance: | Undecided → Critical |
| Changed in cloud-init (Ubuntu Jammy): | |
| importance: | Undecided → Critical |
| Changed in cloud-init (Ubuntu Focal): | |
| importance: | Undecided → Critical |
| Chad Smith (chad.smith) wrote | #1 |
| Changed in cloud-init (Ubuntu Mantic): | |
| status: | New → Fix Committed |
Upstream commit landed for this revert https:/