>> 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 _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
