default not accepted as destination in routes: in the network-config

Hey Pedro, it appears as though the netplan renderer isn't getting selected as it should be, but I need to see the logs to know for sure. Please run 'cloud-init collect-logs' and attach the resulting tarball to this ticket, then you can set the status back to 'New'.

Hi Pedro, Thanks for filing the bug and making cloud-init better.

I can confirm locally with the following:
cat > LP1978543.yaml <<EOF
version: 2
ethernets:
  enp0s3:
    dhcp4: false
    addresses: [10.0.4.10/24]
    nameservers:
      addresses: [10.0.4.1]
    routes:
    - to: default
      via: 10.0.4.1
      metric: 100
EOF

PYTHONPATH=. python3 -m cloudinit.cmd.main devel net-convert -m enp0s3,AA -O netplan --k yaml -p LP1978543.yaml -D ubuntu -d out
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/csmith/src/cloud-init/cloudinit/cmd/main.py", line 1073, in <module>
    return_value = main(sys.argv)
  File "/home/csmith/src/cloud-init/cloudinit/cmd/main.py", line 1059, in main
    retval = util.log_time(
  File "/home/csmith/src/cloud-init/cloudinit/util.py", line 2621, in log_time
    ret = func(*args, **kwargs)
  File "/home/csmith/src/cloud-init/cloudinit/cmd/devel/net_convert.py", line 136, in handle_args
    ns = network_state.parse_net_config_data(pre_ns)
  File "/home/csmith/src/cloud-init/cloudinit/net/network_state.py", line 1056, in parse_net_config_data
    nsi.parse_config(skip_broken=skip_broken)
  File "/home/csmith/src/cloud-init/cloudinit/net/network_state.py", line 279, in parse_config
    self.parse_config_v2(skip_broken=skip_broken)
  File "/home/csmith/src/cloud-init/cloudinit/net/network_state.py", line 328, in parse_config_v2
    handler(self, command)
  File "/home/csmith/src/cloud-init/cloudinit/net/network_state.py", line 721, in handle_ethernets
    subnets = self._v2_to_v1_ipcfg(cfg)
  File "/home/csmith/src/cloud-init/cloudinit/net/network_state.py", line 880, in _v2_to_v1_ipcfg
    _normalize_route(
  File "/home/csmith/src/cloud-init/cloudinit/net/network_state.py", line 1019, in _normalize_route
    _normalize_net_keys(
  File "/home/csmith/src/cloud-init/cloudinit/net/network_state.py", line 953, in _normalize_net_keys
    raise ValueError(f"Address {addr} is not a valid ip address")
ValueError: Address default is not a valid ip address

When I change `to: default` to the alternative `to: 0.0.0.0/0` we render correctly without error
csmith@uptown:~/src/cloud-init$ PYTHONPATH=. python3 -m cloudinit.cmd.main devel net-convert -m enp0s3,AA -O netplan --k yaml -p LP1978543.yaml -D ubuntu -d out
Read input format 'yaml' from 'LP1978543.yaml'.
Wrote output format 'netplan' to 'out/'

csmith@uptown:~/src/cloud-init$ cat out/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:
        enp0s3:
            addresses:
            - 10.0.4.10/24
            dhcp4: false
            nameservers:
                addresses:
                - 10.0.4.1
            routes:
            - metric: 100
      ...

At the moment 0.0.0.0/0 instead of default should work for network config.

Ultimately cloud-init needs a allow "default" in cloudinit.net.network_state as it will pass it through directly the netplan renderer reserved word "default" in config v2 support.

That said other renderers will not be able to support a "default" value so we may have some renderer impacts as we try to support this "default" value.

Looks like the "to: default" support was added in netplan.io in this commit https://github.com/canonical/netplan/commit/7844058d
which was in netplan version:

$ git describe 7844058d
0.98-129-g7844058

Bionic and later have the following netplan:
0.99-0ubuntu3~18.04.5

Thanks Chad for digging in here. Zooming out a little bit, I think there's a bigger mismatch between what's happening here and our docs.

In our v2 config, [1] states (under the routes section): "Each mapping includes a to, via key with an IPv4 or IPv6 address as value." V2 has never promised to be full compatibility with netplan, so if this were happening on a non-netplan system, I would consider the error to be expected behavior.

However, since at the top of the document [2] we claim that "On a system with netplan present, cloud-init will pass Version 2 configuration through to netplan without modification", I think that the real bug here is that we're trying to parse the v2 config at all. I think we should instead check the version number and the renderer, and if it's v2 on netplan, hand the config off directly to netplan without any additional checking.

[1]: https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#common-properties-for-all-device-types
[2]: https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#netplan-passthrough

>> I think that the real bug here is that we're trying to parse the v2 config at all. I think we should instead check the version number and the renderer, and if it's v2 on netplan, hand the config off directly to netplan without any additional checking.

James, you are right. We had a discussion to sort this as well and I agree with the approach of network_state not being touched when cloud-init is provided raw v2 and we have chosen the render to netplan. Then clean passthrough is observed.

That said, other distros will still use cloud-init's built-in network config v2 support which is a subset of raw netplan. And you linked to the documented warnings about that behavior.

Let's mark this high then so we can ensure clean passthrough when on netplan and get out of the way on those systems.

Attached is the requested .tar.gz on a fresh VM just a couple of minutes before...
This was done with focal, but I can confirm the same behaviour on jammy.

See https://github.com/canonical/cloud-init/pull/1650

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