> On Mon, Dec 14, 2015 at 12:31:45PM -0800, Adam Williamson wrote:
> > The situation is not at all the same; there is no clear expectation
> > that networkd will replace NetworkManager, indeed AFAIK it's been
> > explicitly stated that it won't, because it's not desirable for it to
> > cover all the complex configurations NM supports.
>
> One development (mostly) since we started talking about this is that NM
> is now much more modular, and has a "configure and go away" mode (the
> lack of which was the main reason for not using it in the cloud image
> in the first place). It also can use the same lightweight DHCP library
> that systemd does, which in either case is an advantage over ye olde
> memory-hungry reference implementation as used by the initscripts
> networking.
>
> I'm not saying it's the automatic winner over systemd-networkd, but all
> that should be taken into consideration.
Correct, still configuring networkd seems to be easier in my eyes. I
also forget to mention that CoreOS is using networkd from 2014. Major
What other distros are doing, whether Ubuntu above, or CoreOS, or any
of them is completely irrelevant for a discussion about Fedora.
Overall for a data centre / cloud use case both NetworkManager and
systemd-networkd provide similar functionality and these days it
appears similar resource utilization.
In terms of functionality needed in a datacentre you need things like:
* bonding
* teaming
* bridging
* VLANs
* tunnelling
* routing
All of which are provided by both. In a datacentre you don't tend to
need things like wifi/bluetooth and friends and even in the
vagrant/image on a laptop that's handled by the host OS.
Anaconda uses NetworkManager, no idea what cockpit uses. It's also
likely that it should be reviewed from a Server WG PoV too as it's
likely not a good idea to use two different ones between Cloud and
Server products, consistency here is likely best.
The biggest concern I have is QA, the cloud WG in the 23 cycle dropped
the ball on testing and if the Cloud WG chooses to deviate from the
rest of the project I would want to see a very detailed plan for QAing
of the stack so we don't end up in the same situation we did in the
last cycle.
Peter