23.2: cloudinit.sources.parse_cmdline of ds=nocloud-net on kernel cmdline does not parse hyphens
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
cloud-init (Ubuntu) | Status tracked in Mantic | |||||
Focal |
Fix Released
|
Undecided
|
Unassigned | |||
Jammy |
Fix Released
|
Undecided
|
Unassigned | |||
Kinetic |
Fix Released
|
Undecided
|
Unassigned | |||
Lunar |
Fix Released
|
Undecided
|
Unassigned | |||
Mantic |
Fix Released
|
Critical
|
Unassigned |
Bug Description
[ Impact ]
Regression in 23.2 release prevented cloud-init from honoring datasource detection of from the kernel commandline parameter `ds=nocloud-net;s=http://
Inability to correct parse `ds=nocloud-net` from the commandline meant that cloud-init would detect DataSourceNone and no configuration applied to the system on boot.
This typically would result in symtoms like inability to SSH to the VM/container that is launched on platforms which make use of kernel commandline params to set the cloud-init datasource type to nocloud-net and use seed URL to obtain remote configuration from an HTTP service.
Although augmenting kernel commandline is not a typical install pattern for most cloud platforms, this regression has been discovered in iPXE boot environments which may want to customize cloud-init behavior per image launch with configuration from a separate local HTTP-based service on the local/private network.
[ Test Plan ]
1. Provide an HTTP URL or service which surfaces a directory containing: user-data, meta-data and vendor-data
2. Launch a kvm instance in lxd
3. Augment GRUB_CMDLINE_LINUX= to specify ds=nocloud-
4. grub-mkconfig
5. reboot the VM
6. Confirm datasorce detected is nocloud (not "none") from: cloud-init query platform
7. Confirm instance-data was pulled from the remote URL seed from: cloud-init query subplatform
Said test plan is already implemented and included in Jenkins test runners of cloud-init integration tests[1] which are run nightly by Jenkins w/ success.
[ Where problems could occur ]
This error condition and fix only affects NoCloud datasource for cases where ds=nocloud-net is provided on as kernel commandline parameter. It will not affect any major clouds as they have separate datasources and typically do not use kernel command line params to strictly set/override the cloud-init datasource to detect.
If cloud-init fails to detect the datasource, cloud-init platform will report cloud-id == `none` and no user-data/meta-data configuration would be applied to the system. This typically results in inability ssh into a launched instance
This also does not affect NoCloud datasource which is can still detect nocloud configuration via the filesystem in the default seed directory /var/lib/
[ Other Info ]
Given that this impact is limited to NoCloudNet where kernel cmdline params are provided to override default behavior of cloud-init.
Verification on this SRU bug should probably be limited to:
1. specific test to NoCloudNet datasource as defined above
2. Supplemental full jenkins test run of NoCloud KVM and container suite to ensure no regression in any other LXD related behavior.
[ Original Description ]
Affects: cloud-init 23.2 which is already released to Mantic, and uploaded to the following -proposed suites:
focal-proposed
jammy-proposed
kinetic-proposed
lunar-proposed
This represents and SRU verification regresssion that we do not want to release to the related updates suites on stable releases.
Upstream bug filed https:/
Commit 612b4de introduced parse_cmdline function which did
not take into account hyphenated datasource names.
This function is only used by DataSourceNoCloud and no longer can detect nocloud-net datasource.
This results in DataSourceNone being detected and no NoCloud datasources applied to a launched container/VM.
description: | updated |
description: | updated |
description: | updated |
description: | updated |
This bug was fixed in the package cloud-init - 23.3~1ge5a617fe -0ubuntu1
--------------- e-0ubuntu1) mantic; urgency=medium
cloud-init (23.3~1ge5a617f
* Upstream snapshot based on upstream/main at e5a617fe.
- Bugs fixed in this snapshot: (LP: #2025180, #2025180, #1999952)
(LP: #1798055)
-- Chad Smith <email address hidden> Wed, 28 Jun 2023 09:57:55 -0600