** Description changed: [ 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 - + 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
** Description changed: [ 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. + 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 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 + 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 ** Description changed: [ 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 + Upstream fixes: + - https://github.com/canonical/cloud-init/pull/5321 + - https://github.com/canonical/cloud-init/pull/5361 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2066985 Title: EC2 multi-nic ENI rendering fails if ENI activator not used To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2066985/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
