Invalid network config dictionaries are not handled well

[Ryan Harper]

Empty or invalid network configurations are not handled gracefully:

network:
  version: 1
  config: []

network:
  foo: 27
  wark: True

These result in errors during rendering like this:

File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 570, in render_network_state
    network_state).items():
  File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 541, in _render_sysconfig
    for iface in network_state.iter_interfaces():
AttributeError: 'NoneType' object has no attribute 'iter_interfaces'

    r.render_network_state(network_state=ns, target=args.directory)
  File "/home/rharper/work/git/cloud-init/cloudinit/net/netplan.py", line 218, in render_network_state
    content = self._render_content(network_state)
  File "/home/rharper/work/git/cloud-init/cloudinit/net/netplan.py", line 257, in _render_content
    interfaces = network_state._network_state.get('interfaces', [])
AttributeError: 'NoneType' object has no attribute '_network_state'

It appears that cloudinit.net.network_state.parse_* and the NetworkStateInterpretor does not do enough validation.

In general we should decide how to handle these two types of configurations (empty and invalid) and allow cloud-init to fail gracefully, for example, cloud-init could use fallback_network config in the case of an invalid supplied network configuration.

[Dan Watkins (oddbloke)]

I've confirmed locally that this is still an issue, but it's not clear to me how many places might provide empty/broken configuration, so I'm not sure what the priority should be.

[DanyChen (danychen)]

bridges:
  br-lan:
    dhcp4: false
    addresses:
      - 10.0.0.1/24
      - fd00::1/60
    interfaces: []
    parameters:
      stp: false

this throws me an error, I use hostapd to join the bridge so the interfaces is empty, normally this should be ok! I think all array property should take empty into consideration.

[Dan Watkins (oddbloke)]

Hey DanyChen, thanks for using cloud-init, and for taking the time to comment. I've just quickly tested that network configuration locally, and it doesn't seem to cause an error for me. Would you be able to open up a new bug with further details? (If it turns out to be the same as this one, we can always mark it as duplicate. :)

Thanks!

[Dan Watkins (oddbloke)]

I've just tested the two configs given as examples here; the invalid config produces this traceback in the logs:

2021-01-26 14:42:56,084 - util.py[DEBUG]: failed stage init-local
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 653, in status_wrapper
    ret = functor(name, args)
  File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 362, in main_init
    init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
  File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 699, in apply_network_config
    self.distro.networking.wait_for_physdevs(netcfg)
  File "/usr/lib/python3/dist-packages/cloudinit/distros/networking.py", line 140, in wait_for_physdevs
    physdevs = self.extract_physdevs(netcfg)
  File "/usr/lib/python3/dist-packages/cloudinit/distros/networking.py", line 45, in extract_physdevs
    return net.extract_physdevs(netcfg)
  File "/usr/lib/python3/dist-packages/cloudinit/net/__init__.py", line 502, in extract_physdevs
    raise RuntimeError('Unknown network config version: %s' % version)
RuntimeError: Unknown network config version: None

and the empty config is handled gracefully: no errors (and empty configuration written out for netplan).

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2969