Hi! I see a similar issue with the latest (development) netplan, where
some OVS services are triggered via systemd service units (same as
wpa_supplicant service units in the case of WiFi).
On first boot (with cloud-init user.network-config provided [0]) I can
see that the services are not being started at all. While on subsequent
boots (or after executing 'netplan apply' manually), the services are
started and everything works as expected:
==== FIRST BOOT ====
root@ovs-y:~# systemctl status netplan-ovs-cleanup
● netplan-ovs-cleanup.service - OpenVSwitch configuration for cleanup
Loaded: loaded (/run/systemd/system/netplan-ovs-cleanup.service;
enabled-runtime; vendor preset: enabled)
Active: inactive (dead)
root@ovs-y:~# systemctl status netplan-ovs-ovs0
● netplan-ovs-ovs0.service - OpenVSwitch configuration for ovs0
Loaded: loaded (/run/systemd/system/netplan-ovs-ovs0.service;
enabled-runtime; vendor preset: enabled)
Active: inactive (dead)
==== REBOOT ====
root@ovs-y:~# systemctl status netplan-ovs-cleanup
● netplan-ovs-cleanup.service - OpenVSwitch configuration for cleanup
Loaded: loaded (/run/systemd/system/netplan-ovs-cleanup.service;
enabled-runtime; vendor preset: enabled)
Active: inactive (dead) since Fri 2020-07-31 11:02:57 UTC; 2s ago
Process: 325 ExecStart=/usr/sbin/netplan apply --only-ovs-cleanup
(code=exited, status=0/SUCCESS)
Main PID: 325 (code=exited, status=0/SUCCESS)
root@ovs-y:~# systemctl status netplan-ovs-ovs0
● netplan-ovs-ovs0.service - OpenVSwitch configuration for ovs0
Loaded: loaded (/run/systemd/system/netplan-ovs-ovs0.service;
enabled-runtime; vendor preset: enabled)
Active: inactive (dead) since Fri 2020-07-31 11:02:57 UTC; 5min ago
Process: 326 ExecStart=/usr/bin/ovs-vsctl --may-exist add-br ovs0
(code=exited, status=0/SUCCESS)
Process: 343 ExecStart=/usr/bin/ovs-vsctl --may-exist add-port ovs0 eth0.21
(code=exited, status=0/SUCCESS)
Process: 344 ExecStart=/usr/bin/ovs-vsctl set Bridge ovs0
external-ids:netplan=true (code=exited, status=0/SUCCESS)
Process: 345 ExecStart=/usr/bin/ovs-vsctl set-fail-mode ovs0 standalone
(code=exited, status=0/SUCCESS)
Process: 346 ExecStart=/usr/bin/ovs-vsctl set Bridge ovs0
mcast_snooping_enable=false (code=exited, status=0/SUCCE>
Process: 347 ExecStart=/usr/bin/ovs-vsctl set Bridge ovs0 rstp_enable=false
(code=exited, status=0/SUCCESS)
Main PID: 347 (code=exited, status=0/SUCCESS)
Jul 31 11:02:57 ovs-y systemd[1]: Starting OpenVSwitch configuration for ovs0...
Jul 31 11:02:57 ovs-y ovs-vsctl[326]: ovs|00001|vsctl|INFO|Called as
/usr/bin/ovs-vsctl --may-exist add-br ovs0
Jul 31 11:02:57 ovs-y ovs-vsctl[343]: ovs|00001|vsctl|INFO|Called as
/usr/bin/ovs-vsctl --may-exist add-port ovs0 eth0>
Jul 31 11:02:57 ovs-y ovs-vsctl[344]: ovs|00001|vsctl|INFO|Called as
/usr/bin/ovs-vsctl set Bridge ovs0 external-ids:n>
Jul 31 11:02:57 ovs-y ovs-vsctl[345]: ovs|00001|vsctl|INFO|Called as
/usr/bin/ovs-vsctl set-fail-mode ovs0 standalone
Jul 31 11:02:57 ovs-y ovs-vsctl[346]: ovs|00001|vsctl|INFO|Called as
/usr/bin/ovs-vsctl set Bridge ovs0 mcast_snooping>
Jul 31 11:02:57 ovs-y ovs-vsctl[347]: ovs|00001|vsctl|INFO|Called as
/usr/bin/ovs-vsctl set Bridge ovs0 rstp_enable=fa>
Jul 31 11:02:57 ovs-y systemd[1]: netplan-ovs-ovs0.service: Succeeded.
Jul 31 11:02:57 ovs-y systemd[1]: Finished OpenVSwitch configuration for ovs0.
==== END ====
I think this is related to cloud-init calling 'netplan generate' during
the boot sequence, which will generate *.netdev, *.network, *.service
and *.wants/*.service units and symlinks (dependencies). The *.netdev
and *.network files (i.e. physical ethernet/wifi interfaces) will be
executed happily, as they are triggered by the network interfaces
appearing. But the *.service units and its dependency symlinks (i.e. OVS
config & wpa_supplicant setup) will not be executed, as this would
require running 'systemctl daemon-reload' to re-calculate the
dependencies, which is not possible during the boot sequence, where
dependencies already have been calculated.
I currently see two solutions to this problem:
1) cloud-init needs to deploy the netplan YAML config from its
DataSource and run 'netplan generate' within it's own systemd cloud-
init-generator (i.e. before the dependencies are calculated). Or just
deploy the YAML really early, before the netplan generator runs, so it
can just do it's job. – Not sure if this is possible, as the DataSources
might not yet be available at that stage.
2) cloud-init needs to execute 'netplan apply' (instead of 'netplan
generate') at a later stage of the boot process. This will update the
network config at runtime, and reset the network shortly (restart
systemd-networkd.service).
What do you think?
Lukas
[0] user.network-config:
user.network-config: |
# cloud-config
version: 2
bridges:
ovs0:
addresses: [10.10.10.20/24]
interfaces: [eth0.21]
parameters:
stp: false
openvswitch: {}
ethernets:
eth0:
addresses: [10.10.10.30/24]
vlans:
eth0.21:
id: 21
link: eth0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1870346
Title:
Wifi configuration
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1870346/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
