Change should clearly justify its costs with respect to NetworkManager
Every other spin/edition/etc, including the atomic image, uses NetworkManager to solve the race condition this change aims to address. Diverging from that would cost us the testing and security benefits we would get by using the same code as the rest of Fedora as well as the similarity of environments that the cloud base image purports to provide its users in the Cloud PRD. The feature page's stated reason for using networkd is to save on disk space, but it should justify why that space savings is worth the costs using it would incur. In particular, it should address:
- How much space savings making users learn an unfamiliar network management stack is worth
- Why we shouldn't merely slim down NetworkManager down by splitting off dependency-heavy and unused components
- Why we shouldn't merely slim down systemd by splitting off networkd and other unused components
- Whether the QA team can reasonably validate a second network management stack for the sake of just one image
- Whether the documentation team can reasonably maintain a second set of network documentation for the sake of just one image
Gholms (talk) 05:10, 23 June 2015 (UTC)
The overall plan is to replace the initscripts network stack. Not only here, but globally. So, the next steps are to replace the initramfs network stack with systemd-networkd and also make NetworkManager optional with generator scripts for the ifcfg-* files, which convert them to systemd-networkd syntax. As this will take some time, we would have a first user here, with what I understand a limited (dhcp only?) use case.