Comment 0 for bug 1997467

Sorry that this is a bit unspecific right now, I will try to provide more details ASAP.

We see failures in our nested core20-early-config test, e.g.
https://github.com/snapcore/snapd/actions/runs/3512986269/jobs/5885568960

The test fails in the following place:
"""
...
+ remote.exec 'sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=false'
+ MATCH false
+ remote.exec sudo 'netplan get bridges.br54.dhcp4'
grep error: pattern not found, got:
true
"""
at this point the files look like this (sudo is now needed which was not before btw):
"""
$ sudo cat /etc/netplan/0-snapd-defaults.yaml
network:
  version: 2
  ethernets:
    ens3:
      addresses:
      - "10.0.2.15/24"
      dhcp4: false
      routes:
      - to: "default"
        via: "10.0.2.2"
  bridges:
    br54:
      dhcp4: true

$ sudo cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp0s2:
            dhcp4: true
            match:
                macaddress: '52:54:00:12:34:56'
            set-name: enp0s2
    version: 2
"""
When I manually run

   $ sudo snap set system system.network.netplan.network.bridges.br54.dhcp4=false

inside the VM I see no error but the file 0-snapd-defaults.yaml is unchanged and no
new file 90-snapd-config is created. The logic inside snapd is that the gadget defaults
are stored as 0-snapd-defaults and later changes are stored in 90-sanpd-config so that
the later config values win over the earlier ones.

Fwiw, this test is also run on a core20 system with netplan 104 and there the same test works succesfully afaict.