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