The test shipped with the netplan support drove only the private
write_netplan_* writers, so it could not see the branch selection that is
the actual fix: deleting the netplan arm from configipv4 outright left all
fourteen assertions green. Its one real-parser gate was vacuous as well --
`netplan generate --root-dir` reads <root>/etc/netplan, and the harness
wrote the drop-ins flat into the scratch directory, so netplan parsed zero
files and exited 0 for any content at all, including a key it rejects.
Drive configipv4, configipv6 and delete_nic_config_files instead, and let
the generate gate see the tree it is meant to validate. netplan, ifup and
wait_for_ifstate are shadowed with shell functions, which bash resolves
ahead of $PATH, so `netplan apply` is recorded rather than run and the
suite cannot touch the host's network however it is invoked.
Two assertions had pinned the behaviour that was wrong: that a VLAN file
declares no ethernets: section -- which is exactly why netplan could not
resolve its link: -- and that the default route reads "to: default", an
alias netplan only understands from 0.103.
The harness now also uses the sentinel configeth really sets rather than
one of its own, so an unset MTU is exercised through the comparison the
script performs instead of past it.
Each assertion was checked by reverting the behaviour it describes: all
nine reversions fail, including the one the previous test was blind to.
On a runner with netplan present the generate gate fails with
"unknown key 'MTU'" when nicextraparams are passed through unmapped.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Ubuntu 18.04 and later render the network with netplan. ifupdown is not installed and
/etc/network/interfaces.d/* is ignored entirely, so configeth's Debian branch -- which
writes exactly there -- configures nothing at all on a modern Ubuntu node. It must
write /etc/netplan/*.yaml and apply it instead. Issue #7454.
Three properties a netplan writer has to hold, all of which an in-place YAML editor
gets wrong. A VLAN interface (<parent>.<vid>) belongs under vlans: with id and link,
or netplan never recreates it after a reboot. Multiple addresses on one NIC must keep
the order they were added. And routes must be idempotent on the whole (to, via) pair,
not on either field alone, or a second route sharing a gateway is swallowed.
nicextraparams must survive as well: the ifupdown branch writes them into the
interface stanza, so a netplan branch that drops them silently discards configuration
the user asked for.
Drive the real writers -- extracted from configeth and run against a temp NETPLAN_DIR
-- and hand the result to `netplan generate` where netplan is installed.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Daniel Hilst