mNo edit summary |
No edit summary |
||
Line 31: | Line 31: | ||
--[[User:Lnykryn|Lnykryn]] ([[User talk:Lnykryn|talk]]) 08:04, 25 June 2015 (UTC) | --[[User:Lnykryn|Lnykryn]] ([[User talk: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. | |||
[[User:Gholms|Gholms]] ([[User talk:Gholms|talk]]) 21:41, 26 June 2015 (UTC) |
Revision as of 21:41, 26 June 2015
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.