| 2023-06-27 21:23:07 |
Chad Smith |
bug |
|
|
added bug |
| 2023-06-27 21:23:20 |
Chad Smith |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-06-27 21:23:20 |
Chad Smith |
bug task added |
|
cloud-init (Ubuntu Lunar) |
|
| 2023-06-27 21:23:20 |
Chad Smith |
nominated for series |
|
Ubuntu Kinetic |
|
| 2023-06-27 21:23:20 |
Chad Smith |
bug task added |
|
cloud-init (Ubuntu Kinetic) |
|
| 2023-06-27 21:23:20 |
Chad Smith |
nominated for series |
|
Ubuntu Focal |
|
| 2023-06-27 21:23:20 |
Chad Smith |
bug task added |
|
cloud-init (Ubuntu Focal) |
|
| 2023-06-27 21:23:20 |
Chad Smith |
nominated for series |
|
Ubuntu Mantic |
|
| 2023-06-27 21:23:20 |
Chad Smith |
bug task added |
|
cloud-init (Ubuntu Mantic) |
|
| 2023-06-27 21:23:20 |
Chad Smith |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-06-27 21:23:20 |
Chad Smith |
bug task added |
|
cloud-init (Ubuntu Jammy) |
|
| 2023-06-27 21:25:13 |
Chad Smith |
description |
Upstream bug filed https://github.com/canonical/cloud-init/issues/4203 detailing that ds=nocloud-net is not longer recognized resulting in DataSourceNone being detected intead of DataSourceNoCloudNet.
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. |
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://github.com/canonical/cloud-init/issues/4203 detailing that ds=nocloud-net is not longer recognized resulting in DataSourceNone being detected intead of DataSourceNoCloudNet.
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. |
|
| 2023-06-28 19:31:51 |
Chad Smith |
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://github.com/canonical/cloud-init/issues/4203 detailing that ds=nocloud-net is not longer recognized resulting in DataSourceNone being detected intead of DataSourceNoCloudNet.
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. |
[ Impact ]
Regression in 23.2 release prevented cloud-init from honoring datasource detection of from the kernel commandline parameter `ds=nocloud-net;s=http://something` with a seed URL instead of local filesystem directory-based seed files.
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-net;s=<YOUR_URL_FROM_1> to specify both ds=nocloud-net and the remote seed URL containing user-data,vendor-data, meta-data
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
[ 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/cloud/seed/nocloud or /var/lib/cloud/seed/nocloud-net. It really is limited to seed URL based configuration for DataSourceNoCloudNet.
[ Other Info ]
[ 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://github.com/canonical/cloud-init/issues/4203 detailing that ds=nocloud-net is not longer recognized resulting in DataSourceNone being detected intead of DataSourceNoCloudNet.
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. |
|
| 2023-06-28 19:34:58 |
Chad Smith |
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://something` with a seed URL instead of local filesystem directory-based seed files.
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-net;s=<YOUR_URL_FROM_1> to specify both ds=nocloud-net and the remote seed URL containing user-data,vendor-data, meta-data
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
[ 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/cloud/seed/nocloud or /var/lib/cloud/seed/nocloud-net. It really is limited to seed URL based configuration for DataSourceNoCloudNet.
[ Other Info ]
[ 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://github.com/canonical/cloud-init/issues/4203 detailing that ds=nocloud-net is not longer recognized resulting in DataSourceNone being detected intead of DataSourceNoCloudNet.
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. |
[ Impact ]
Regression in 23.2 release prevented cloud-init from honoring datasource detection of from the kernel commandline parameter `ds=nocloud-net;s=http://something` with a seed URL instead of local filesystem directory-based seed files.
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-net;s=<YOUR_URL_FROM_1> to specify both ds=nocloud-net and the remote seed URL containing user-data,vendor-data, meta-data
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
[ 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/cloud/seed/nocloud or /var/lib/cloud/seed/nocloud-net. It really is limited to seed URL based configuration for DataSourceNoCloudNet.
[ 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://github.com/canonical/cloud-init/issues/4203 detailing that ds=nocloud-net is not longer recognized resulting in DataSourceNone being detected intead of DataSourceNoCloudNet.
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. |
|
| 2023-06-28 19:36:46 |
Chad Smith |
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://something` with a seed URL instead of local filesystem directory-based seed files.
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-net;s=<YOUR_URL_FROM_1> to specify both ds=nocloud-net and the remote seed URL containing user-data,vendor-data, meta-data
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
[ 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/cloud/seed/nocloud or /var/lib/cloud/seed/nocloud-net. It really is limited to seed URL based configuration for DataSourceNoCloudNet.
[ 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://github.com/canonical/cloud-init/issues/4203 detailing that ds=nocloud-net is not longer recognized resulting in DataSourceNone being detected intead of DataSourceNoCloudNet.
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. |
[ Impact ]
Regression in 23.2 release prevented cloud-init from honoring datasource detection of from the kernel commandline parameter `ds=nocloud-net;s=http://something` with a seed URL instead of local filesystem directory-based seed files.
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-net;s=<YOUR_URL_FROM_1> to specify both ds=nocloud-net and the remote seed URL containing user-data,vendor-data, meta-data
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.
[1] https://github.com/canonical/cloud-init/blob/main/tests/integration_tests/test_kernel_commandline_match.py#L97-L141
[ 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/cloud/seed/nocloud or /var/lib/cloud/seed/nocloud-net. It really is limited to seed URL based configuration for DataSourceNoCloudNet.
[ 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://github.com/canonical/cloud-init/issues/4203 detailing that ds=nocloud-net is not longer recognized resulting in DataSourceNone being detected intead of DataSourceNoCloudNet.
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. |
|
| 2023-06-28 23:06:19 |
Launchpad Janitor |
cloud-init (Ubuntu Mantic): status |
Triaged |
Fix Released |
|
| 2023-06-30 16:51:25 |
Andreas Hasenack |
cloud-init (Ubuntu Lunar): status |
New |
Fix Committed |
|
| 2023-06-30 16:51:27 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-06-30 16:51:30 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
| 2023-06-30 16:51:33 |
Andreas Hasenack |
tags |
|
verification-needed verification-needed-lunar |
|
| 2023-06-30 16:52:59 |
Andreas Hasenack |
cloud-init (Ubuntu Kinetic): status |
New |
Fix Committed |
|
| 2023-06-30 16:53:05 |
Andreas Hasenack |
tags |
verification-needed verification-needed-lunar |
verification-needed verification-needed-kinetic verification-needed-lunar |
|
| 2023-06-30 16:54:05 |
Andreas Hasenack |
cloud-init (Ubuntu Jammy): status |
New |
Fix Committed |
|
| 2023-06-30 16:54:11 |
Andreas Hasenack |
tags |
verification-needed verification-needed-kinetic verification-needed-lunar |
verification-needed verification-needed-jammy verification-needed-kinetic verification-needed-lunar |
|
| 2023-06-30 16:55:34 |
Andreas Hasenack |
cloud-init (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2023-06-30 16:55:40 |
Andreas Hasenack |
tags |
verification-needed verification-needed-jammy verification-needed-kinetic verification-needed-lunar |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-kinetic verification-needed-lunar |
|
| 2023-07-08 22:30:15 |
Chad Smith |
attachment added |
|
sru-2025180.log https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2025180/+attachment/5684837/+files/sru-2025180.log |
|
| 2023-07-08 22:31:02 |
Chad Smith |
tags |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-kinetic verification-needed-lunar |
verification-done verification-done-focal verification-done-jammy verification-done-kinetic verification-done-lunar |
|
| 2023-07-13 23:49:05 |
Launchpad Janitor |
cloud-init (Ubuntu Lunar): status |
Fix Committed |
Fix Released |
|
| 2023-07-13 23:49:17 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2023-07-13 23:49:47 |
Launchpad Janitor |
cloud-init (Ubuntu Kinetic): status |
Fix Committed |
Fix Released |
|
| 2023-07-13 23:50:24 |
Launchpad Janitor |
cloud-init (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-07-13 23:50:48 |
Launchpad Janitor |
cloud-init (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
