Ordering of mapping keys matter

[Blake Rouse]

For some reason it matters the order you define the keys in the network mapping. This just seems incorrect when a mapping doesn't really define an order.

The following fails to work:

network:
  bridges:
    br0:
      addresses:
      - 192.168.122.69/24
      gateway4: 192.168.122.1
      interfaces:
      - ens4
      macaddress: 52:54:00:0d:c0:48
      mtu: 1500
      nameservers:
        addresses:
        - 192.168.122.2
        search:
        - maas
      parameters:
        forward-delay: 15
        stp: false
  ethernets:
    ens4:
      match:
        macaddress: 52:54:00:0d:c0:48
      mtu: 1500
      set-name: ens4
  version: 2

Errors with "Error in network definition /etc/netplan/50-cloud-init.yaml line 12 column 8: br0: interface ens4 is not defined"

If ethernets is placed before bridges then it works correctly. This just seems completely wrong when it comes to writing YAML. If it was a list I would agree the order matters but being a mapping the order should not matter.

The following works:

network:
  ethernets:
    ens4:
      match:
        macaddress: 52:54:00:0d:c0:48
      mtu: 1500
      set-name: ens4
  bridges:
    br0:
      addresses:
      - 192.168.122.69/24
      gateway4: 192.168.122.1
      interfaces:
      - ens4
      macaddress: 52:54:00:0d:c0:48
      mtu: 1500
      nameservers:
        addresses:
        - 192.168.122.2
        search:
        - maas
      parameters:
        forward-delay: 15
        stp: false
  version: 2

[Blake Rouse (blake-rouse)]

This was noticed because MAAS creates a dictionary and then renders the YAML with yaml.dumps which places the order of the keys alphabetically.

https://bugs.launchpad.net/maas/+bug/1817931

[Mathieu Trudel-Lapierre (cyphermox)]

We specifically addressed this kind of issue before; and I can verify that the config presented does work:

netplan.generate:54: DEBUG: running ['./generate', '--root-dir', '../testing/']
(generate:14309): netplan.generate-DEBUG: 13:30:58.971: Processing input file ../testing//etc/netplan/netplan.yaml..
(generate:14309): netplan.parse-DEBUG: 13:30:58.972: starting new processing pass
(generate:14309): netplan.parse-DEBUG: 13:30:58.972: recording missing yaml_node_t ens4
(generate:14309): netplan.parse-DEBUG: 13:30:58.972: starting new processing pass
(generate:14309): netplan.generate-DEBUG: 13:30:59.009: Generating output files..
(generate:14309): netplan.generate.nm-DEBUG: 13:30:59.009: NetworkManager: definition br0 is not for us (backend 1)
(generate:14309): netplan.generate.nm-DEBUG: 13:30:59.010: NetworkManager: definition ens4 is not for us (backend 1)
(generate:14309): GLib-DEBUG: 13:30:59.010: posix_spawn avoided (fd close requested)

It has been available since netplan 0.19; so I'm not sure why you're seeing issues.

https://github.com/CanonicalLtd/netplan/commit/e41215b24f43f5a67ba9f38bd6373a0f75405335

[Blake Rouse (blake-rouse)]

This was deploying Bionic with MAAS. Would that fix be released in Bionic, because I did hit it on Bionic and it is affecting deployments with MAAS.

So if you can provide the source package from bionic has this patch then I will re-test.