Michel Lind just prompted me to notice that the 'network' service appears to have been removed from initscripts in Fedora 40+. This change seems to have landed in February without any fanfare - https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd0... . There is no Change for it, AFAICS.
This does not appear to be driven by upstream removing it, because the commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove it from the build. Presumably without that, it would still be built.
I'm a bit worried about this arriving unannounced and apparently mostly unnoticed. There *are* still reasons to use the network service; I still use it on the openQA worker hosts, for instance, because there is integration between openvswitch and the legacy network service, but no integration between openvswitch and NetworkManager. I also use an ifup- pre-local script to pre-create tap devices; NetworkManager apparently does not support this natively. There's a suggested workaround at https://access.redhat.com/solutions/6900331 , which is helpful, but still, it's a significant change if you're using that mechanism.
As a user of this service, I would've expected more of a heads-up that it was going away; if I hadn't happened to catch Michel's message I might have upgraded openQA staging to F40 immediately on release (as I usually do) and been rather surprised that the network setup stopped working. I'm sure I will find a way to re-engineer this rather complicated network setup without network.service, but a bit more of a heads up would have been nice.
Should this have been a Change? How worried are we about it going out in Fedora 40 without having been through the Change process?
On Fri, 2024-04-12 at 14:40 -0700, Adam Williamson wrote:
unnoticed. There *are* still reasons to use the network service; I still use it on the openQA worker hosts, for instance, because there is integration between openvswitch and the legacy network service, but no integration between openvswitch and NetworkManager.
it seems since I last looked at this, NM has grown some level of openvswitch support, but it seems to be limited, and I don't know off- hand if it's sufficient for what openQA needs. I will need to look into that. https://github.com/NetworkManager/NetworkManager/blob/main/man/nm-openvswitc...
On 4/12/24 16:46, Adam Williamson wrote:
it seems since I last looked at this, NM has grown some level of openvswitch support, but it seems to be limited, and I don't know off- hand if it's sufficient for what openQA needs. I will need to look into that. https://github.com/NetworkManager/NetworkManager/blob/main/man/nm-openvswitc...
I've attempted to use it on a couple occasions, and I've never been able to get it to work. It requires creating 3 different objects, in the correct order, with exactly the right settings.
And AFAIK, it still doesn't support setting the internal port to the same name as the bridge itself, which is the default behavior of ovs-vsctl and the network scripts, so it's a disruptive change to the network configuration even if it can be made to work.
On Fri, Apr 12, 2024 at 05:44:36PM -0500, Ian Pilcher wrote:
On 4/12/24 16:46, Adam Williamson wrote:
it seems since I last looked at this, NM has grown some level of openvswitch support, but it seems to be limited, and I don't know off- hand if it's sufficient for what openQA needs. I will need to look into that. https://github.com/NetworkManager/NetworkManager/blob/main/man/nm-openvswitc...
I've attempted to use it on a couple occasions, and I've never been able to get it to work. It requires creating 3 different objects,
Right, that's because the OVS support in NM is modeled after the ovsdb schema, with separate entities for bridges, ports and interfaces. When you create a bridge with 'ovs-vsctl add-br br1', that actually generates 3 objects:
# ovs-vsctl show Bridge br1 Port br1 Interface br1 type: internal
If there was only a single NM connection profile for the whole bridge, it wouldn't be possible e.g. to attach another interface to port "br1", or to describe more complex setups in a declarative way.
in the correct order, with exactly the right settings.
The order shouldn't matter; if it does, that seems a bug.
If it helps, "man nm-openvswitch" provides an overview of OVS support in NM.
And AFAIK, it still doesn't support setting the internal port to the same name as the bridge itself, which is the default behavior of ovs-vsctl and the network scripts, so it's a disruptive change to the network configuration even if it can be made to work.
This configuration is certainly supported. If you found any problems, please report a bug.
Beniamino
On Fri, Apr 12, 2024 at 4:41 PM Adam Williamson adamwill@fedoraproject.org wrote:
Michel Lind just prompted me to notice that the 'network' service appears to have been removed from initscripts in Fedora 40+. This change seems to have landed in February without any fanfare - https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd0... . There is no Change for it, AFAICS.
This does not appear to be driven by upstream removing it, because the commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove it from the build. Presumably without that, it would still be built.
I'm a bit worried about this arriving unannounced and apparently mostly unnoticed. There *are* still reasons to use the network service; I still use it on the openQA worker hosts, for instance, because there is integration between openvswitch and the legacy network service, but no integration between openvswitch and NetworkManager. I also use an ifup- pre-local script to pre-create tap devices; NetworkManager apparently does not support this natively. There's a suggested workaround at https://access.redhat.com/solutions/6900331 , which is helpful, but still, it's a significant change if you're using that mechanism.
As a user of this service, I would've expected more of a heads-up that it was going away; if I hadn't happened to catch Michel's message I might have upgraded openQA staging to F40 immediately on release (as I usually do) and been rather surprised that the network setup stopped working. I'm sure I will find a way to re-engineer this rather complicated network setup without network.service, but a bit more of a heads up would have been nice.
Should this have been a Change? How worried are we about it going out in Fedora 40 without having been through the Change process?
This should have been an announced Change. This is a significant change with wide impact.
On Fri, 2024-04-12 at 19:03 -0500, Neal Gompa wrote:
On Fri, Apr 12, 2024 at 4:41 PM Adam Williamson adamwill@fedoraproject.org wrote:
Michel Lind just prompted me to notice that the 'network' service appears to have been removed from initscripts in Fedora 40+. This change seems to have landed in February without any fanfare - https://src.fedoraproject.org/rpms/initscripts/c/414789841de9247310ebfd37cd0... . There is no Change for it, AFAICS.
This does not appear to be driven by upstream removing it, because the commit apparently specifically adds 'NO_NETWORK_SCRIPTS=true' to remove it from the build. Presumably without that, it would still be built.
I'm a bit worried about this arriving unannounced and apparently mostly unnoticed. There *are* still reasons to use the network service; I still use it on the openQA worker hosts, for instance, because there is integration between openvswitch and the legacy network service, but no integration between openvswitch and NetworkManager. I also use an ifup- pre-local script to pre-create tap devices; NetworkManager apparently does not support this natively. There's a suggested workaround at https://access.redhat.com/solutions/6900331 , which is helpful, but still, it's a significant change if you're using that mechanism.
As a user of this service, I would've expected more of a heads-up that it was going away; if I hadn't happened to catch Michel's message I might have upgraded openQA staging to F40 immediately on release (as I usually do) and been rather surprised that the network setup stopped working. I'm sure I will find a way to re-engineer this rather complicated network setup without network.service, but a bit more of a heads up would have been nice.
Should this have been a Change? How worried are we about it going out in Fedora 40 without having been through the Change process?
This should have been an announced Change. This is a significant change with wide impact.
I've filed a bug, proposed it as a blocker, and filed a FESCo ticket asking FESCo to designate the bug as a blocker.
https://bugzilla.redhat.com/show_bug.cgi?id=2274830 https://pagure.io/fesco/issue/3196
On Fri, Apr 12, 2024 at 06:00:41PM -0700, Adam Williamson wrote:
This should have been an announced Change. This is a significant change with wide impact.
I've filed a bug, proposed it as a blocker, and filed a FESCo ticket asking FESCo to designate the bug as a blocker.
https://bugzilla.redhat.com/show_bug.cgi?id=2274830 https://pagure.io/fesco/issue/3196
I admit I was also initially surprised. But, this actually has been going through the Change process for a while:
F33: https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifc... F36: https://fedoraproject.org/wiki/Changes/NoIfcfgFiles F39: https://fedoraproject.org/wiki/Changes/MigrateIfcfgToKeyfile
That last one actually says:
The upstream NetworkManager project has recently declared the ifcfg plugin as deprecated. This means that the code will only receive bug fixes, and will not get new functionality such as supporting new properties.
With this change, existing profiles in ifcfg format will be automatically migrated to the native keyfile format via a migration service shipped with the NetworkManager-initscripts-ifcfg-rh package. In Fedora, we plan to drop the plugin by Fedora Linux 41.
(Emphasis on the last line.)
The words "the network-scripts subpackage is deprecated and will be removed" do not seem to have appeared in the release notes, and in retrospect that probably should have been stronger.
"Gone in 40" _does_ technically fit into the letter of "drop by 41"... but maybe not the spirit?
I think a "drop in 41" change (and a clear item in the F40 release notes!) is probably the best way to clear the air -- but I don't think the maintainers stepped around the process here.
Once upon a time, Matthew Miller mattdm@fedoraproject.org said:
With this change, existing profiles in ifcfg format will be automatically migrated to the native keyfile format via a migration service shipped with the NetworkManager-initscripts-ifcfg-rh package. In Fedora, we plan to drop the plugin by Fedora Linux 41.
(Emphasis on the last line.)
The words "the network-scripts subpackage is deprecated and will be removed" do not seem to have appeared in the release notes, and in retrospect that probably should have been stronger.
"Gone in 40" _does_ technically fit into the letter of "drop by 41"... but maybe not the spirit?
Dropping the NM ifcfg plugin is very different from dropping the actual old network scripts.
On Sat, 2024-04-13 at 18:17 -0400, Matthew Miller wrote:
On Fri, Apr 12, 2024 at 06:00:41PM -0700, Adam Williamson wrote:
This should have been an announced Change. This is a significant change with wide impact.
I've filed a bug, proposed it as a blocker, and filed a FESCo ticket asking FESCo to designate the bug as a blocker.
https://bugzilla.redhat.com/show_bug.cgi?id=2274830 https://pagure.io/fesco/issue/3196
I admit I was also initially surprised. But, this actually has been going through the Change process for a while:
F33: https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifc... F36: https://fedoraproject.org/wiki/Changes/NoIfcfgFiles F39: https://fedoraproject.org/wiki/Changes/MigrateIfcfgToKeyfile
I would argue that it has not. Those Changes are all about the NetworkManager plugin that reads ifcfg files. The network service - /etc/init.d/network - is a different thing. They may be tied together in the maintainers' minds, I don't know, but they are not tied together technically and none of those Changes, IMHO, at all clearly conveys "the network service is going away in Fedora 40".
Just for record, the removal of network-scripts was done because https://fedoraproject.org/wiki/Changes/dhclient_deprecation
Network-scripts heavily depend on dhclient and there is no plan to rework them to use a different dhcp implementation.
ne 14. 4. 2024 v 17:14 odesílatel Adam Williamson < adamwill@fedoraproject.org> napsal:
On Sat, 2024-04-13 at 18:17 -0400, Matthew Miller wrote:
On Fri, Apr 12, 2024 at 06:00:41PM -0700, Adam Williamson wrote:
This should have been an announced Change. This is a significant change with wide impact.
I've filed a bug, proposed it as a blocker, and filed a FESCo ticket asking FESCo to designate the bug as a blocker.
https://bugzilla.redhat.com/show_bug.cgi?id=2274830 https://pagure.io/fesco/issue/3196
I admit I was also initially surprised. But, this actually has been going through the Change process for a while:
F33:
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifc...
F36: https://fedoraproject.org/wiki/Changes/NoIfcfgFiles F39: https://fedoraproject.org/wiki/Changes/MigrateIfcfgToKeyfile
I would argue that it has not. Those Changes are all about the NetworkManager plugin that reads ifcfg files. The network service - /etc/init.d/network - is a different thing. They may be tied together in the maintainers' minds, I don't know, but they are not tied together technically and none of those Changes, IMHO, at all clearly conveys "the network service is going away in Fedora 40". -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, Apr 15, 2024 at 10:46:39AM +0200, Lukáš Nykrýn wrote:
Just for record, the removal of network-scripts was done because https://fedoraproject.org/wiki/Changes/dhclient_deprecation
That page has Category:ChangePageIncomplete. dhcp-client is present in F40, even though it has Provides:deprecated().
Network-scripts heavily depend on dhclient and there is no plan to rework them to use a different dhcp implementation.
Ack. So it sounds like we could keep using both in F40 and prepare for removal in F41.
Zbyszek
On Mon, 2024-04-15 at 10:44 +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Apr 15, 2024 at 10:46:39AM +0200, Lukáš Nykrýn wrote:
Just for record, the removal of network-scripts was done because https://fedoraproject.org/wiki/Changes/dhclient_deprecation
That page has Category:ChangePageIncomplete. dhcp-client is present in F40, even though it has Provides:deprecated().
Network-scripts heavily depend on dhclient and there is no plan to rework them to use a different dhcp implementation.
Ack. So it sounds like we could keep using both in F40 and prepare for removal in F41.
There are various uses of the service that do not need a DHCP client, like the one I referred to in the bug report and FESCo ticket. Heck, you can kinda *assume* anyone still using the service at this point is doing something weird with it, not just a 'normal' "bring up this interface for me with DHCP" kinda thing.
The removal of the network service should still be treated as its own significant operation, not a natural consequence of the removal of dhclient.
Just for record, the removal of network-scripts was done because https://fedoraproject.org/wiki/Changes/dhclient_deprecation
That page has Category:ChangePageIncomplete. dhcp-client is present in F40, even though it has Provides:deprecated().
Network-scripts heavily depend on dhclient and there is no plan to rework them to use a different dhcp implementation.
Ack. So it sounds like we could keep using both in F40 and prepare for removal in F41.
There are various uses of the service that do not need a DHCP client, like the one I referred to in the bug report and FESCo ticket. Heck, you can kinda *assume* anyone still using the service at this point is doing something weird with it, not just a 'normal' "bring up this interface for me with DHCP" kinda thing.
The removal of the network service should still be treated as its own significant operation, not a natural consequence of the removal of dhclient.
The System-V scripts are also deprecated since systemd v254 so eventually they'll be going away too:
https://lists.freedesktop.org/archives/systemd-devel/2023-August/049349.html
The System-V scripts are also deprecated since systemd v254 so eventually they'll be going away too:
https://lists.freedesktop.org/archives/systemd-devel/2023-August/049349.html
This change should be reverted in Fedora. The "systemd cabal"'s hatred of SysV is insufficient justification for this dropping a 'network' service, and there exist myriad third-party tools that prefer imperative control over their start process anyway.
On Mon, Apr 15, 2024 at 09:20:32PM -0000, Japheth J.C. Cleaver wrote:
The System-V scripts are also deprecated since systemd v254 so eventually they'll be going away too:
https://lists.freedesktop.org/archives/systemd-devel/2023-August/049349.html
This change should be reverted in Fedora. The "systemd cabal"'s hatred of SysV is insufficient justification for this dropping a 'network' service, and there exist myriad third-party tools that prefer imperative control over their start process anyway.
Regardless of whether you agree with deprecating SysV or not, network-scripts' removal from Fedora has nothing to do with the "systemd cabal" - indeed, the systemd maintainer in Fedora, zbyszek, voted in favor of restoring network-scripts earlier today.
Best regards, and let's treat each other respectfully,
On Sun, Apr 14, 2024 at 08:13:30AM -0700, Adam Williamson wrote:
On Sat, 2024-04-13 at 18:17 -0400, Matthew Miller wrote:
On Fri, Apr 12, 2024 at 06:00:41PM -0700, Adam Williamson wrote:
This should have been an announced Change. This is a significant change with wide impact.
I've filed a bug, proposed it as a blocker, and filed a FESCo ticket asking FESCo to designate the bug as a blocker.
https://bugzilla.redhat.com/show_bug.cgi?id=2274830 https://pagure.io/fesco/issue/3196
I admit I was also initially surprised. But, this actually has been going through the Change process for a while:
F33: https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifc... F36: https://fedoraproject.org/wiki/Changes/NoIfcfgFiles F39: https://fedoraproject.org/wiki/Changes/MigrateIfcfgToKeyfile
I would argue that it has not. Those Changes are all about the NetworkManager plugin that reads ifcfg files. The network service - /etc/init.d/network - is a different thing.
Right, the changes above are about NetworkManager dropping support for reading and writing ifcfg files. There is no direct relation with the network service and its removal.
Beniamino
They may be tied together in the maintainers' minds, I don't know, but they are not tied together technically and none of those Changes, IMHO, at all clearly conveys "the network service is going away in Fedora 40". -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, Apr 12, 2024 at 9:41 PM Adam Williamson adamwill@fedoraproject.org wrote:
Michel Lind just prompted me to notice that the 'network' service appears to have been removed from initscripts in Fedora 40+.
....
Should this have been a Change? How worried are we about it going out in Fedora 40 without having been through the Change process?
I think it should have been better documented (i.e. called out in a change proposal for feedback), but I am going to suggest systemd-networkd as the longer term better solution (but that would be for another day).