The GCE datasource is changing the behavior of the network interfaces that follow. Ideally the system should fallback to the same networking state regardless of the list of datasources that is provided.
This is similar to #4680, following the change of #4163 a datasource that follows GCE will get a different network environment than before. This behavior is observed on multi-nic hosts and in particular a host that has DHCP available on the first interface and no DHCP on the second interface.
This creates an issue where the host needs to boot in a mixture of environments that have an available datasource and those that do not.
Steps to reproduce the problem
Have a VM that is configured with DHCP enabled on primary interface and no DHCP on secondary interface. Do not provide any cloud-init datasources:
The simplest method to reproduce to is to boot two hosts that have a datasource of:
this will work as expected
[NoCloud, None]
and
this will not work as expected
[ GCE, NoCloud, None]
In the first non-GCE example the system will have the following network state following the boot:
root@ubuntu:~# cat /etc/cloud/cloud.cfg.d/90_dpkg.cfg
# to update this file, run dpkg-reconfigure cloud-init
datasource_list: [ NoCloud, None ]
root@ubuntu:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether bc:24:11:08:98:e0 brd ff:ff:ff:ff:ff:ff
altname enp0s18
inet 192.168.1.193/24 metric 100 brd 192.168.1.255 scope global dynamic ens18
valid_lft 84651sec preferred_lft 84651sec
inet6 fd53:e24d:b056:ead5:be24:11ff:fe08:98e0/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 1762sec preferred_lft 1762sec
inet6 fe80::be24:11ff:fe08:98e0/64 scope link
valid_lft forever preferred_lft forever
3: ens19: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether bc:24:11:6e:1a:bf brd ff:ff:ff:ff:ff:ff
altname enp0s19
In the second GCE example the system will have the following networking state
root@ubuntu:~# cat /etc/cloud/cloud.cfg.d/90_dpkg.cfg
# to update this file, run dpkg-reconfigure cloud-init
datasource_list: [ GCE, NoCloud, None ]
root@ubuntu:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether bc:24:11:08:98:e0 brd ff:ff:ff:ff:ff:ff
altname enp0s18
3: ens19: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether bc:24:11:6e:1a:bf brd ff:ff:ff:ff:ff:ff
altname enp0s19
Environment details
Cloud-init version: 24.2-0ubuntu1~24.04.2
Operating System Distribution: Ubuntu
Cloud provider, platform or installer type:
cloud-init logs
there's no logs because it appears to occur during the search phase of looking for a datasource
Bug report
The GCE datasource is changing the behavior of the network interfaces that follow. Ideally the system should fallback to the same networking state regardless of the list of datasources that is provided.
This is similar to #4680, following the change of #4163 a datasource that follows GCE will get a different network environment than before. This behavior is observed on multi-nic hosts and in particular a host that has DHCP available on the first interface and no DHCP on the second interface.
This creates an issue where the host needs to boot in a mixture of environments that have an available datasource and those that do not.
Steps to reproduce the problem
Have a VM that is configured with DHCP enabled on primary interface and no DHCP on secondary interface. Do not provide any cloud-init datasources:
The simplest method to reproduce to is to boot two hosts that have a datasource of:
this will work as expected
[NoCloud, None]
and
this will not work as expected
[ GCE, NoCloud, None]
In the first non-GCE example the system will have the following network state following the boot:
In the second GCE example the system will have the following networking state
Environment details
cloud-init logs
there's no logs because it appears to occur during the search phase of looking for a datasource