Ticket #615 requires packages wanting to keep initscripts to file for an exception. This is such a request for /etc/init.d/network script.
= background analysis = initscripts currently has two initscripts: - /etc/init.d/netconsole, which isn't too complicated and Lukas Nykryn volunteered to convert it to an oneshot unit. - /etc/init.d/network, which contains a lot of code. There are replacements (NetworkManager, and systemd-network), but they are not drop-in, and either bring additional dependencies (NetworkManager), or aren't complete and supported (systemd-networkd). There are also no plans to do further work on initscripts' network script, since it is planned to be dropped in the future. /etc/init.d/network still has users, so we want to keep it.
/etc/init.d/network is just a big shell script, so wrapping it in systemd unit wouldn't change anything, unless it was heavily modified, and there are no volunteers for that.
We'll discuss this in the meeting tomorrow at 17:00 UTC on #fedora-meeting
Netconsole should just be dropped and people referred to https://fedoraproject.org/wiki/Netconsole once it has been updated to reflect how it should be done.
/etc/modules-load.d/netconsole.conf
netconsole
/etc/modprobe.d/netconsole.conf
options netconsole netconsole=@192.168.1.2/enp1s2, at 192.168.1.1/
/etc/sysctl.d/10-netconsole.conf
kernel.printk = 8 4 1 7
Arguably systemd-networkd is good enough as the core/baseOS replacement for the legacy network initscript suitable for the cloud/container as well as serverWG with NM covering what ever it does not ( or simply default to NM and drop it )
I agree with Johann with replacing network by systemd-networkd, my only concern is about making sure that documentation follow up this change as this was widely used.
If network to systemd-networkd upgrade is documented properly, then why bothering keeping network which has no future. Both Workstation and Server products are relying on NM, and for Cloud, it's not even used.
I also agree that we should replace network-scripts with systemd. But first we need a dbus interface in networkd and than we need a compatibility wrappers for the stuff like ifup. Also networkd and NM are missing some legacy stuff like ISDN modems.
It's easy to say "network scripts should by replaced by systemd-networkd". Even if upstream provides all the capabilities, implementing the transition in Fedora is yet another thing. Writing documentation, answering questions, dealing with the inevitable fallout. It might be worth the trouble, but so far nobody has committed to do the work. And I don't think we should try to do that, systemd-networkd is still being developed, and once the dbus api is merged, the transition to systemd-networkd might be much easier.
"nobody has committed to do the work."
That tends to happened when you have committees and company pretending to know better then the people actually trying to do all that work while protecting their "customers" interest or other projects within the company in the process.
If and then when Denise/Bill/Tom( Spot or those really in charge of the project there in phoenix ) have discussed adding/including networkd in RHEL 8 ( F24 would be the time to start preparing for that ) and or the exact released and agreed upon it, then people from the community might appear willing to lend a hand to the baseWG ( people aren't participating in the wg's in general unless they are a voting member which is just foreseeable, logical and expected progress of such implementation ) or even driving that work since things will go a lot smoother when they have.
That said where does the requirement that systemd needs an dbus interface come from in the first place?
Administrators have been using ifconfig/ip/nmtui ( atleast here on these parts ) not ifup and ifdown and the likes for quite sometime now so where does the requirement for that come from?
I don't get why the D-Bus API should matter here, but nevermind. If nobody commits to document the transition from network to systemd-networkd, we can't approve that change.
@johannbg: our decision has nothing to do with RHEL8 roadmap or whatever, if someone comes up with a sound plan, it'll have my +1 at least.
Replying to [comment:8 hguemar]:
I don't get why the D-Bus API should matter here, but nevermind
Currently the only way to change configuration managed by systemd-networkd is to restart systemd-networkd. The d-bus api will be way to mutate state incrementally. Restarting and blowing current state away is fine for many use cases, but not for the more complex ones.
If nobody commits to document the transition from network to systemd-networkd, we can't approve that change.
What do you mean by "that change"? AFAIK nobody proposed any changes.
Yeah. I don't really know what Denise and Spot and other people have to do with this. There is absolutely no reason to bring them in.
Replying to [comment:9 zbyszek]:
Replying to [comment:8 hguemar]: I don't get why the D-Bus API should matter here, but nevermind Currently the only way to change configuration managed by systemd-networkd is to restart systemd-networkd. The d-bus api will be way to mutate state incrementally. Restarting and blowing current state away is fine for many use cases, but not for the more complex ones.
It's more or less already the case for network. As none of the 3 products uses network currently as default, it could be acceptable to lose some features to a certain extent.
If nobody commits to document the transition from network to systemd-networkd, we can't approve that change. What do you mean by "that change"? AFAIK nobody proposed any changes.
I meant the informal change suggested by Johann but you're correct that no formal changes was submitted. In any case, it has to be more than "drop network and tell people to use networkd". Due to network long existence, we have to provide a transition path between the two tools, period.
@johannbg: our decision has nothing to do with RHEL8 roadmap or whatever, if someone comes up with a sound plan, it'll have my +1 at least. Yeah. I don't really know what Denise and Spot and other people have to do with this. There is absolutely no reason to bring them in.
As you point out later none of the "official" products uses network currently as default which leaves the upgrade path ( which arguably is only "supported" thus tested for those exact same products that are not using it in the first place right ) which afaik boils down to...
a) Documentation ( netconsole, networkd ) b) Make initscript entirely optional component c) create a generator ( which btw Lukas wrote over a year ago [1] ) which ends up in the initscript and be the only thing that the initscript ships.
I can take care of the documentation part as well as take a look at the components that require initscript and fix that.
Lukas need comment why he wants to delay ( continue shipping ) something he was working on complete removal over a year ago which strikes me a bit odd that he does not want to complete that work.
Replying to [comment:11 johannbg]:
Replying to [comment:8 hguemar]: I don't get why the D-Bus API should matter here, but nevermind. If nobody commits to document the transition from network to systemd-networkd, we can't approve that change. As you point out later none of the "official" products uses network currently as default which leaves the upgrade path ( which arguably is only "supported" thus tested for those exact same products that are not using it in the first place right ) which afaik boils down to...
This is inccorect https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks#n42 cloud uses network and removes NetworkManager
That generator is not finished and unfortunately I have been busy with other things. But the code is on github so pull requests or forks are welcome.
We discussed this in Friday's FESCo meeting and agreed on the following:
AGREED: initscript exception for initscripts package approved (+1:7, 0:1, -1:0) (kalev, 18:17:43)
https://meetbot.fedoraproject.org/fedora-meeting/2016-01-22/fesco.2016-01-22-17.02.html
Granting exception or at least granting exception without conditions of deprecation plan being in place is just silly ( as Stephen points out through out those discussions as well as Jared ).
So I'm just going to start walking through what was discussed on that meeting
" <lnykryn> we need to keep it, there are 3rd party legacy scripts which depends on it"
This is not a valid argument since a) the direction of the distribution cannot be held back by <unknown> 3rd party's and b) accepting it as such FESCo has effectively sent the message that if you are a package maintainer in Fedora you are no longer allowed to ship legacy sysv initscripts in the package that you maintain but if you just so happen to be a 3rd party it's OK to do just that since it's "supported" so kudos for contributing to the decision making with an end result that leads to less participation in the project since people and company are better of not doing so.
"<nirik> retiring this when networkd is more featurefull"
Kevin it would be good if you could clarify what you mean by that. What does networkd and network manager not do today what initstcript already does. ( this should prove to be very interesting since the networkscript support is just a scripted mess parching text files and calling modprope,ip,nmcli and systemd commands )
And FYI retiring this when networkd is more "feature full" or when ever Lukas decided to do that ( initscripts are still shipping crap that relies on pand which got what deprecated in 2007 o_O I guess people put different meaning in what constitutes as package maintenance since for example this should have been deprecated at the same time it was ) is irrelevant since it's up to the WG's to chose it's replacement which might either be networkd or network manager so this deprecation and it's replacements needs to support both thus is independent of either networkd or network manager.
Now I ask all those voted plus on not deprecated this and granting this exception.
What does fesco expect to be done so this component can be deprecated and within what timeframe should that work be completed and is transitioning just to networkd considered enough in that regard?
Login to comment on this ticket.