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.
Harald (talk) 15:30, 24 June 2015 (UTC)
Just for curiosity, I have tried to compare the sizes of minimal images on rhel, where we (unfortunately) have separate systemd-networkd.
[root@notas ~]# yum -y --nogpg --installroot=/srv/networkd/ --disablerepo='*' --enablerepo=rhel7 install systemd passwd yum vim redhat-release-workstation systemd-networkd [root@notas ~]# yum -y --nogpg --installroot=/srv/NM/ --disablerepo='*' --enablerepo=rhel7 install systemd passwd yum vim redhat-release-workstation NetworkManager [root@notas ~]# yum -y --nogpg --installroot=/srv/initscripts/ --disablerepo='*' --enablerepo=rhel7 install systemd passwd yum vim redhat-release-workstation initscripts [root@notas ~]# yum -y --nogpg --installroot=/srv/empty/ --disablerepo='*' --enablerepo=rhel7 install systemd passwd yum vim redhat-release-workstation [root@notas ~]# du -s /srv/NM /srv/networkd /srv/initscripts /srv/empty | sort -n 447024 /srv/empty 447028 /srv/networkd 456616 /srv/initscripts 491452 /srv/NM
And Harald already answered those two last questions. We will have to do it anyway, because we definitely want to drop initscripts (and I say that with my initscripts-maintainer hat on).
--Lnykryn (talk) 08:04, 25 June 2015 (UTC)
That we need to replace the initscripts networking stuff is not in dispute. What this change should elaborate on is why we should use networkd to do it instead of using the same solution as the rest of Fedora. So far the extent of that justification boils down to, "It uses less disk space, given the way packages are broken down today." It doesn't yet mention the additional documentation and testing work, nor does it address its apparent conflict with the Cloud PRD's goal of simplifying deployment of code by avoiding surprises from differences in one's environment. Our developer product, Workstation, uses NetworkManager; if we want Cloud to use networkd perhaps we should make that change in concert with Workstation.
Gholms (talk) 21:41, 26 June 2015 (UTC)
It should be taken into account when comparing NM and networkd, that this sort of minimal setup is different from the typical NM usecase and precisely what networkd was written for. The usage of NM on a workstation is completely different from the use of NM in a cloud image. One is almost certainly using a GUI and the other is most probably using static configuration files, so at any rate you probably want targeted documentation for the cloud case. Moreover, the testing and documentation work should be relatively minimal considering the cloud image's limited usecases compared to say the workstation image. It might also be worth looking at how CoreOS has been doing this (as they have been using networkd since early 2014) and also the work going on in Ubuntu/Debian to switch from their ifupdown stuff to networkd. Whatever is decided, upstream networkd would of course be delighted to have another serious user, and we would be happy to work with you guys to get this integrated. Tomegun (talk) 18:34, 30 June 2015 (UTC)
One of the idea behind the products is about different products following different path. Workstation may continue with NM, but we, the Cloud WG can choose networkd for the same work. As the upstream author mentioned above, this will give us same user experience in many other cloud distributions.