| 2024-05-23 20:51:10 |
James Falcon |
bug |
|
|
added bug |
| 2024-05-23 20:52:09 |
James Falcon |
description |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
[ Where problems could occur ]
If the renderer is still somehow misdetecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
[ Other Info ]
Upstream bug:
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
[ Where problems could occur ]
If the renderer is still somehow misdetecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
|
| 2024-05-23 20:52:38 |
James Falcon |
nominated for series |
|
Ubuntu Oracular |
|
| 2024-05-23 20:52:38 |
James Falcon |
bug task added |
|
cloud-init (Ubuntu Oracular) |
|
| 2024-05-23 20:52:38 |
James Falcon |
nominated for series |
|
Ubuntu Mantic |
|
| 2024-05-23 20:52:38 |
James Falcon |
bug task added |
|
cloud-init (Ubuntu Mantic) |
|
| 2024-05-23 20:52:38 |
James Falcon |
nominated for series |
|
Ubuntu Noble |
|
| 2024-05-23 20:52:38 |
James Falcon |
bug task added |
|
cloud-init (Ubuntu Noble) |
|
| 2024-05-23 20:52:38 |
James Falcon |
nominated for series |
|
Ubuntu Jammy |
|
| 2024-05-23 20:52:38 |
James Falcon |
bug task added |
|
cloud-init (Ubuntu Jammy) |
|
| 2024-05-23 20:52:38 |
James Falcon |
nominated for series |
|
Ubuntu Focal |
|
| 2024-05-23 20:52:38 |
James Falcon |
bug task added |
|
cloud-init (Ubuntu Focal) |
|
| 2024-05-24 12:51:11 |
Chad Smith |
summary |
Mutli-nic ENI rendering fails if ENI activator not used |
EC2 multi-nic ENI rendering fails if ENI activator not used |
|
| 2024-05-24 23:18:28 |
Launchpad Janitor |
cloud-init (Ubuntu Oracular): status |
New |
Fix Released |
|
| 2024-05-29 13:27:22 |
Peteris Rudzusiks |
bug |
|
|
added subscriber Peteris Rudzusiks |
| 2024-06-04 10:35:09 |
Peteris Rudzusiks |
bug |
|
|
added subscriber Krister Johansen |
| 2024-06-05 17:10:02 |
Chad Smith |
cloud-init (Ubuntu Oracular): status |
Fix Released |
New |
|
| 2024-06-05 17:12:17 |
Chad Smith |
cloud-init (Ubuntu Oracular): status |
New |
Fix Released |
|
| 2024-06-05 18:05:40 |
Chad Smith |
description |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
[ Where problems could occur ]
If the renderer is still somehow misdetecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SRCE=ppa:cloud-init-dev/daily CLOUD_INIT_PLATFORM=ec2 .tox/integration-tests/bin/pytest tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
If the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
|
| 2024-06-05 19:49:40 |
Chad Smith |
description |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SRCE=ppa:cloud-init-dev/daily CLOUD_INIT_PLATFORM=ec2 .tox/integration-tests/bin/pytest tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
If the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
If the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
|
| 2024-06-05 19:50:11 |
Chad Smith |
description |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
If the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
On EC2 only, if the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur on Ec2 only in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
|
| 2024-06-05 19:51:16 |
Chad Smith |
description |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
On EC2 only, if the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur on Ec2 only in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fix: https://github.com/canonical/cloud-init/pull/5321 |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
On EC2 only, if the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur on Ec2 only in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fixes:
- https://github.com/canonical/cloud-init/pull/5321
- https://github.com/canonical/cloud-init/pull/5361 |
|
| 2024-06-06 19:09:43 |
Andreas Hasenack |
cloud-init (Ubuntu Noble): status |
New |
Fix Committed |
|
| 2024-06-06 19:09:45 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-06-06 19:09:49 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
| 2024-06-06 19:09:54 |
Andreas Hasenack |
tags |
|
verification-needed verification-needed-noble |
|
| 2024-06-06 19:12:30 |
Andreas Hasenack |
cloud-init (Ubuntu Mantic): status |
New |
Fix Committed |
|
| 2024-06-06 19:12:36 |
Andreas Hasenack |
tags |
verification-needed verification-needed-noble |
verification-needed verification-needed-mantic verification-needed-noble |
|
| 2024-06-06 19:13:16 |
Andreas Hasenack |
cloud-init (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2024-06-06 19:13:24 |
Andreas Hasenack |
tags |
verification-needed verification-needed-mantic verification-needed-noble |
verification-needed verification-needed-focal verification-needed-mantic verification-needed-noble |
|
| 2024-06-06 19:13:58 |
Andreas Hasenack |
cloud-init (Ubuntu Jammy): status |
New |
Fix Committed |
|
| 2024-06-06 19:14:05 |
Andreas Hasenack |
tags |
verification-needed verification-needed-focal verification-needed-mantic verification-needed-noble |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-noble |
|
| 2024-06-07 20:20:46 |
James Falcon |
description |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
On EC2 only, if the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur on Ec2 only in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fixes:
- https://github.com/canonical/cloud-init/pull/5321
- https://github.com/canonical/cloud-init/pull/5361 |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
On EC2 only, if the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur on Ec2 only in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fixes:
- https://github.com/canonical/cloud-init/pull/5321
- https://github.com/canonical/cloud-init/pull/5361 |
|
| 2024-06-07 20:22:04 |
James Falcon |
description |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
On EC2 only, if the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur on Ec2 only in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fixes:
- https://github.com/canonical/cloud-init/pull/5321
- https://github.com/canonical/cloud-init/pull/5361 |
[ Impact ]
Cloud-init recently added policy-based routing for netplan-only systems on EC2. In order to gate the netplan-specific code, it checked to see in the netplan activator was being used. However, if the datasource is fetched in init-local timeframe (such as on EC2), it is possible to specify a different renderer without also changing the activator. This means the netplan-gating no longer works, even when rendering to a non-netplan system.
The fix is to instead check if we're using the netplan renderer before rendering the netplan-specific code.
[ Test Plan ]
Launch an Ubuntu instance on EC2 having two NICs attached.
Run "apt update; apt install ifupdown"
In /etc/cloud/cloud.cfg, update the `renderers` line to start with `eni` rather than `netplan`
`cloud-init clean --logs --reboot`
Connect to instance
Verify no networking related tracebacks exist in logs
Verify /etc/network/interfaces.d/ contains valid networking information for both NICs.
Run tests/integration_tests/modules/test_hotplug.py and
tests/integration_tests/test_networking.py
to ensure no regression to existing multinic rendering behavior.
Specifically this test per series is known to assert proper behavior and show potential regressions for netplan-based environments
CLOUD_INIT_OS_IMAGE=jammy CLOUD_INIT_CLOUD_INIT_SOURCE=<YOUR_DEB_FROM_PROPOSED> CLOUD_INIT_PLATFORM=ec2 tox -e integration-tests -- tests/integration_tests/modules/test_hotplug.py::test_multi_nic_hotplug_vpc
[ Where problems could occur ]
On EC2 only, if the renderer is still somehow mis-detecting a netplan or non-netplan based system, we could still attempt to render netplan config where we shouldn't be, or instead skip rendering the config where we shouldn't be.
Problems cloud also occur on Ec2 only in netplan-based images if cloud-init incorrectly determines that netplan is not the configured renderer and skips adding supplmental policy based routes with route-metrics when rendering netplan config for secondary NIC route-metrics.
[ Other Info ]
Upstream bug: https://github.com/canonical/cloud-init/issues/5318
Upstream fixes:
- https://github.com/canonical/cloud-init/pull/5321
- https://github.com/canonical/cloud-init/pull/5361 |
|
| 2024-06-11 21:40:32 |
James Falcon |
attachment added |
|
2066985.tar.gz https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2066985/+attachment/5788564/+files/2066985.tar.gz |
|
| 2024-06-11 21:47:33 |
James Falcon |
tags |
verification-needed verification-needed-focal verification-needed-jammy verification-needed-mantic verification-needed-noble |
verification-done verification-done-focal verification-done-jammy verification-done-mantic verification-done-noble |
|
| 2024-06-13 21:59:17 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-06-13 21:59:29 |
Launchpad Janitor |
cloud-init (Ubuntu Noble): status |
Fix Committed |
Fix Released |
|
| 2024-06-13 21:59:44 |
Launchpad Janitor |
cloud-init (Ubuntu Mantic): status |
Fix Committed |
Fix Released |
|
| 2024-06-13 22:00:09 |
Launchpad Janitor |
cloud-init (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2024-06-13 22:00:35 |
Launchpad Janitor |
cloud-init (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
