| 2024-02-26 19:25:09 |
James Falcon |
bug |
|
|
added bug |
| 2024-02-26 19:26:04 |
James Falcon |
description |
[ Impact ]
In cloud-init 23.4, specifying a datasource via the SMBIOS is broken. This is due to a commit that fixed another bug of cloud-init assuming a datasource list consisting of one datasource and 'None' doesn't need to check for the existence of that datasource. The fix here is to ensure we're always checking for the SMBIOS information, whereas in the past we didn't need to because of the automatic datasource assumption.
[ Test Plan ]
An integration test is being added upstream as part of https://github.com/canonical/cloud-init/pull/4949 . This test currently fails if run against 23.4. If it passes, it demonstrates that the fix works. The test specifies a datasource seed directory via SMBIOS and ensures that the userdata contained within that seed ran correctly. It can be run manually using:
tox -e integration-tests -- tests/integration_tests/datasources/test_nocloud.py::test_smbios_seed
[ Where problems could occur ]
Since this code sits at the interaction of datasources discovered and found via ds-identify and python, along with bits of fallback code to dmidecode, we could have missed an interaction here that could possibly mis-identify the NoCloud datasource in other ways.
[ Other Info ]
Documentation of specifying NoCloud datasource via SMBIOS :
https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#method-2-local-filesystem-kernel-commandline-or-smbios
PR with change that broke the cloud-init behavior:
https://github.com/canonical/cloud-init/pull/4426
Upstream PR fixing the behavior:
https://github.com/canonical/cloud-init/pull/4949 |
[ Impact ]
In cloud-init 23.4, specifying a datasource via the SMBIOS is broken. This is due to a commit that fixed another bug of cloud-init assuming a datasource list consisting of one datasource and 'None' doesn't need to check for the existence of that datasource. The fix here is to ensure we're always checking for the SMBIOS information, whereas in the past we didn't need to because of the automatic datasource assumption.
[ Test Plan ]
An integration test is being added upstream as part of https://github.com/canonical/cloud-init/pull/4949 . This test currently fails if run against 23.4. If it passes, it demonstrates that the fix works. The test specifies a datasource seed directory via SMBIOS and ensures that the userdata contained within that seed ran correctly. It can be run manually using:
tox -e integration-tests -- tests/integration_tests/datasources/test_nocloud.py::test_smbios_seed
[ Where problems could occur ]
Since this code sits at the interaction of datasources discovered and found via ds-identify and python, along with bits of fallback code to dmidecode, we could have missed an interaction here that could possibly mis-identify the NoCloud datasource in other ways.
[ Other Info ]
Documentation of specifying NoCloud datasource via SMBIOS :
https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#method-2-local-filesystem-kernel-commandline-or-smbios
Upstream PR with change that broke the cloud-init behavior:
https://github.com/canonical/cloud-init/pull/4426
Upstream PR fixing the behavior:
https://github.com/canonical/cloud-init/pull/4949 |
|
| 2024-02-26 19:26:29 |
James Falcon |
nominated for series |
|
Ubuntu Jammy |
|
| 2024-02-26 19:26:29 |
James Falcon |
bug task added |
|
cloud-init (Ubuntu Jammy) |
|
| 2024-02-26 19:26:29 |
James Falcon |
nominated for series |
|
Ubuntu Mantic |
|
| 2024-02-26 19:26:29 |
James Falcon |
bug task added |
|
cloud-init (Ubuntu Mantic) |
|
| 2024-02-26 19:26:29 |
James Falcon |
nominated for series |
|
Ubuntu Focal |
|
| 2024-02-26 19:26:29 |
James Falcon |
bug task added |
|
cloud-init (Ubuntu Focal) |
|
| 2024-02-26 19:28:11 |
James Falcon |
tags |
|
regression-update |
|
| 2024-02-27 15:10:36 |
James Falcon |
description |
[ Impact ]
In cloud-init 23.4, specifying a datasource via the SMBIOS is broken. This is due to a commit that fixed another bug of cloud-init assuming a datasource list consisting of one datasource and 'None' doesn't need to check for the existence of that datasource. The fix here is to ensure we're always checking for the SMBIOS information, whereas in the past we didn't need to because of the automatic datasource assumption.
[ Test Plan ]
An integration test is being added upstream as part of https://github.com/canonical/cloud-init/pull/4949 . This test currently fails if run against 23.4. If it passes, it demonstrates that the fix works. The test specifies a datasource seed directory via SMBIOS and ensures that the userdata contained within that seed ran correctly. It can be run manually using:
tox -e integration-tests -- tests/integration_tests/datasources/test_nocloud.py::test_smbios_seed
[ Where problems could occur ]
Since this code sits at the interaction of datasources discovered and found via ds-identify and python, along with bits of fallback code to dmidecode, we could have missed an interaction here that could possibly mis-identify the NoCloud datasource in other ways.
[ Other Info ]
Documentation of specifying NoCloud datasource via SMBIOS :
https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#method-2-local-filesystem-kernel-commandline-or-smbios
Upstream PR with change that broke the cloud-init behavior:
https://github.com/canonical/cloud-init/pull/4426
Upstream PR fixing the behavior:
https://github.com/canonical/cloud-init/pull/4949 |
[ Impact ]
In cloud-init 23.4, specifying a datasource via the SMBIOS is broken. This is due to a commit that fixed another bug of cloud-init assuming a datasource list consisting of one datasource and 'None' doesn't need to check for the existence of that datasource. The fix here is to ensure we're always checking for the SMBIOS information, whereas in the past we didn't need to because of the automatic datasource assumption.
[ Test Plan ]
An integration test is being added upstream as part of https://github.com/canonical/cloud-init/pull/4949 . This test currently fails if run against 23.4. If it passes, it demonstrates that the fix works. The test specifies an http datasource seed via SMBIOS and ensures that the userdata contained within that seed ran correctly. It can be run manually using:
tox -e integration-tests -- tests/integration_tests/datasources/test_nocloud.py::test_smbios_seed_network
[ Where problems could occur ]
Since this code sits at the interaction of datasources discovered and found via ds-identify and python, along with bits of fallback code to dmidecode, we could have missed an interaction here that could possibly mis-identify the NoCloud datasource in other ways.
[ Other Info ]
Documentation of specifying NoCloud datasource via SMBIOS :
https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#method-2-local-filesystem-kernel-commandline-or-smbios
Upstream PR with change that broke the cloud-init behavior:
https://github.com/canonical/cloud-init/pull/4426
Upstream PR fixing the behavior:
https://github.com/canonical/cloud-init/pull/4949 |
|
| 2024-02-27 15:11:10 |
James Falcon |
description |
[ Impact ]
In cloud-init 23.4, specifying a datasource via the SMBIOS is broken. This is due to a commit that fixed another bug of cloud-init assuming a datasource list consisting of one datasource and 'None' doesn't need to check for the existence of that datasource. The fix here is to ensure we're always checking for the SMBIOS information, whereas in the past we didn't need to because of the automatic datasource assumption.
[ Test Plan ]
An integration test is being added upstream as part of https://github.com/canonical/cloud-init/pull/4949 . This test currently fails if run against 23.4. If it passes, it demonstrates that the fix works. The test specifies an http datasource seed via SMBIOS and ensures that the userdata contained within that seed ran correctly. It can be run manually using:
tox -e integration-tests -- tests/integration_tests/datasources/test_nocloud.py::test_smbios_seed_network
[ Where problems could occur ]
Since this code sits at the interaction of datasources discovered and found via ds-identify and python, along with bits of fallback code to dmidecode, we could have missed an interaction here that could possibly mis-identify the NoCloud datasource in other ways.
[ Other Info ]
Documentation of specifying NoCloud datasource via SMBIOS :
https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#method-2-local-filesystem-kernel-commandline-or-smbios
Upstream PR with change that broke the cloud-init behavior:
https://github.com/canonical/cloud-init/pull/4426
Upstream PR fixing the behavior:
https://github.com/canonical/cloud-init/pull/4949 |
[ Impact ]
In cloud-init 23.4, specifying a datasource via the SMBIOS is broken. This is due to a commit that fixed another bug of cloud-init assuming a datasource list consisting of one datasource and 'None' doesn't need to check for the existence of that datasource. The fix here is to ensure we're always checking for the SMBIOS information, whereas in the past we didn't need to because of the automatic datasource assumption.
[ Test Plan ]
An integration test has been added upstream as part of https://github.com/canonical/cloud-init/pull/4949 . This test fails if run against 23.4. If it passes, it demonstrates that the fix works. The test specifies an http datasource seed via SMBIOS and ensures that the userdata contained within that seed ran correctly. It can be run manually using:
tox -e integration-tests -- tests/integration_tests/datasources/test_nocloud.py::test_smbios_seed_network
[ Where problems could occur ]
Since this code sits at the interaction of datasources discovered and found via ds-identify and python, along with bits of fallback code to dmidecode, we could have missed an interaction here that could possibly mis-identify the NoCloud datasource in other ways.
[ Other Info ]
Documentation of specifying NoCloud datasource via SMBIOS :
https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#method-2-local-filesystem-kernel-commandline-or-smbios
Upstream PR with change that broke the cloud-init behavior:
https://github.com/canonical/cloud-init/pull/4426
Upstream PR fixing the behavior:
https://github.com/canonical/cloud-init/pull/4949 |
|
| 2024-02-27 15:13:10 |
Chad Smith |
cloud-init (Ubuntu): status |
New |
In Progress |
|
| 2024-02-27 18:36:36 |
Chad Smith |
cloud-init (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2024-02-27 18:38:23 |
Chad Smith |
cloud-init (Ubuntu): assignee |
|
James Falcon (falcojr) |
|
| 2024-02-27 18:38:28 |
Chad Smith |
cloud-init (Ubuntu): importance |
Undecided |
High |
|
| 2024-02-27 18:38:35 |
Chad Smith |
cloud-init (Ubuntu Focal): status |
New |
In Progress |
|
| 2024-02-27 18:38:37 |
Chad Smith |
cloud-init (Ubuntu Jammy): status |
New |
In Progress |
|
| 2024-02-27 18:38:39 |
Chad Smith |
cloud-init (Ubuntu Mantic): status |
New |
In Progress |
|
| 2024-02-28 00:14:29 |
Chris Halse Rogers |
cloud-init (Ubuntu Mantic): status |
In Progress |
Fix Committed |
|
| 2024-02-28 00:14:30 |
Chris Halse Rogers |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-02-28 00:14:41 |
Chris Halse Rogers |
bug |
|
|
added subscriber SRU Verification |
| 2024-02-28 00:14:44 |
Chris Halse Rogers |
tags |
regression-update |
regression-update verification-needed verification-needed-mantic |
|
| 2024-02-28 00:17:53 |
Chris Halse Rogers |
cloud-init (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2024-02-28 00:17:58 |
Chris Halse Rogers |
tags |
regression-update verification-needed verification-needed-mantic |
regression-update verification-needed verification-needed-jammy verification-needed-mantic |
|
| 2024-02-28 00:26:41 |
Chris Halse Rogers |
cloud-init (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2024-02-28 00:26:47 |
Chris Halse Rogers |
tags |
regression-update verification-needed verification-needed-jammy verification-needed-mantic |
regression-update verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
|
| 2024-02-28 02:24:22 |
Launchpad Janitor |
cloud-init (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2024-02-28 20:00:21 |
James Falcon |
attachment added |
|
23.4.4.tar.gz https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2055081/+attachment/5750421/+files/23.4.4.tar.gz |
|
| 2024-02-28 20:01:39 |
James Falcon |
tags |
regression-update verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic |
regression-update verification-done verification-done-focal verification-done-jammy verification-done-mantic |
|
| 2024-02-28 20:07:43 |
James Falcon |
description |
[ Impact ]
In cloud-init 23.4, specifying a datasource via the SMBIOS is broken. This is due to a commit that fixed another bug of cloud-init assuming a datasource list consisting of one datasource and 'None' doesn't need to check for the existence of that datasource. The fix here is to ensure we're always checking for the SMBIOS information, whereas in the past we didn't need to because of the automatic datasource assumption.
[ Test Plan ]
An integration test has been added upstream as part of https://github.com/canonical/cloud-init/pull/4949 . This test fails if run against 23.4. If it passes, it demonstrates that the fix works. The test specifies an http datasource seed via SMBIOS and ensures that the userdata contained within that seed ran correctly. It can be run manually using:
tox -e integration-tests -- tests/integration_tests/datasources/test_nocloud.py::test_smbios_seed_network
[ Where problems could occur ]
Since this code sits at the interaction of datasources discovered and found via ds-identify and python, along with bits of fallback code to dmidecode, we could have missed an interaction here that could possibly mis-identify the NoCloud datasource in other ways.
[ Other Info ]
Documentation of specifying NoCloud datasource via SMBIOS :
https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#method-2-local-filesystem-kernel-commandline-or-smbios
Upstream PR with change that broke the cloud-init behavior:
https://github.com/canonical/cloud-init/pull/4426
Upstream PR fixing the behavior:
https://github.com/canonical/cloud-init/pull/4949 |
[ Impact ]
In cloud-init 23.4, specifying a datasource via the SMBIOS is broken. This is due to a commit that fixed another bug of cloud-init assuming a datasource list consisting of one datasource and 'None' doesn't need to check for the existence of that datasource. The fix here is to ensure we're always checking for the SMBIOS information, whereas in the past we didn't need to because of the automatic datasource assumption.
[ Test Plan ]
An integration test has been added upstream as part of https://github.com/canonical/cloud-init/pull/4949 . This test fails if run against 23.4. If it passes, it demonstrates that the fix works. The test specifies an http datasource seed via SMBIOS and ensures that the userdata contained within that seed ran correctly. It can be run manually using:
tox -e integration-tests -- tests/integration_tests/datasources/test_nocloud.py::test_smbios_seed_network
[ Where problems could occur ]
Since this code sits at the interaction of datasources discovered and found via ds-identify and python, along with bits of fallback code to dmidecode, we could have missed an interaction here that could possibly mis-identify the NoCloud datasource in other ways.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/4945
Upstream dup: https://github.com/canonical/cloud-init/issues/4951
Documentation of specifying NoCloud datasource via SMBIOS :
https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#method-2-local-filesystem-kernel-commandline-or-smbios
Upstream PR with change that broke the cloud-init behavior:
https://github.com/canonical/cloud-init/pull/4426
Upstream PR fixing the behavior:
https://github.com/canonical/cloud-init/pull/4949 |
|
| 2024-02-29 17:17:59 |
Launchpad Janitor |
cloud-init (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
| 2024-02-29 17:18:01 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-02-29 17:18:13 |
Launchpad Janitor |
cloud-init (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2024-02-29 17:18:28 |
Launchpad Janitor |
cloud-init (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
