Hi Mark,

Here are my two cents regarding Ubuntu network management tooling.
This reflection is based on my daily tasks as an architect but also as an operator.

I think that one thing we should have a look at first is if it supports appropriate professional/enterprise required features such as Macvlan interface creation, Teaming with LACP, LLDP configuration etc.
I didn't have a complete look over all of them, but at least they all "seems" to support teaming and bonding, didn't tested macvlan interfaces on netplan and systemd-networkd tho.

Another topic of interest is how we're easing operators' lives, if netplan is the de facto solution on Ubuntu Servers release and that operators are used to dealing with it and that it is stable, let it go!

* Netplan:
Ubuntu default tool, but ubuntu only tool that risks to be squeezed anytime the same way unity was years ago.
Just a simple wrapper over network backends such as systemd-networkd or NetworkManager, could easily be replaced with Ansible or any configuration manager.
On the other hand, it's the Ubuntu defacto and operators may be used to it.

* systemd-networkd:
Even if the idea is elegant, this network backend is having issues attracting developers contributors and its lack of integration within RHEL/CentOS because of that: https://bugzilla.redhat.com/show_bug.cgi?id=1650342 should really ring a bell to anyone.
Nothing much to say, it's configuration units could easily be generated with ansible once again (I'm thinking of that because of the underlying kayobe context), so netplan would be almost redundant.
In the meantime, it is available through EPEL repository if we ever choose to use it so we could keep some consistency between supported distributions.

* NetworkManager: (Be ready, long explanation, but I think we need it to get rid of some I.T urban legends and misconceptions)
"Bloated with default dependencies'' (plugins that extend it to support interfaces type/link type/etc) and "Does too much" was indeed relevant years ago, but honestly these internet rumors are over exaggerated and here it's why (factually).

Strictly speaking NM only requires dbus-glib and libndp packages if built manually: http://www.linuxfromscratch.org/blfs/view/stable-systemd/basicnet/networkmanager.html

Anything more is just because distributions are created for general purposes and so provide it with most requested dependencies and plugins that let NM manage PPP/Teaming/WWAN/etc.
Within CentOS-8 Those default dependencies aren't huge at all as it only request for the following dependencies: https://centos.pkgs.org/8/centos-baseos-x86_64/NetworkManager-1.26.0-12.el8_3.x86_64.rpm.html
As you can see many required dependencies are already satisfied by the system itself to work correctly. Such as systemd/dbus/libc/libudev/ld etc, some even aren't installed on server oriented installations such as everything glib2 related.
Overall it is 10MB (package + dependencies size).
Depending on your KS or installation type you are then provided with additional but useful packages depending on your situation such as: NetworkManager-ovs / NetworkManager-team / NetworkManager-dispatcher-routing-rules etc.

Now, regarding "Does too much", it was a real issue a few years ago, but is no longer relevant. For sure it will consider any new interface to be under control but it doesn't touch them until instructed otherwise. With a fresh Kolla-ansible install for instance, your neutron (OVS only install) interfaces on compute nodes are listed and seen by nmcli (qbr and tap devices) but it just list them, it doesn't interact with them until you decide it or not, on my own I'm really finding that useful but this is strictly personal.

I hope this feedback will help you.
Bye.

Le ven. 12 févr. 2021 à 13:21, Mark Goddard <mark@stackhpc.com> a écrit :
Hi,

We're working on adding Ubuntu support to Kayobe, and are at the stage
of deciding on which tool to use for host network configuration. The
Ansible role we use supports /etc/network/interfaces, but we're
thinking it might be sensible to choose something more modern before
we get locked in. There are 3 reasonable options, as far as we can
tell:

* netplan: installed by default on 20.04 server images. Seems like a
fairly simple solution, but I have read some reports of missing
features.

* systemd-networkd: the default renderer for netplan. Standard systemd
style interface. We might get around the missing features by using
this directly.

* NetworkManager: the default on Ubuntu desktop, but have heard it can
be a bit heavy and does too much without being asked to. I've also
heard that more recent versions are improved. The main reason we would
go this route would be for consistency with CentOS/RHEL.

Any feedback of experience with these and their suitability for use in
OpenStack cloud infrastructure would be appreciated.

Thanks,
Mark