Open Stack

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210212/fbfc8eef/attachment.html>