Hide Forgot
We are interested in replacing the legacy initscripts network scripts (or NetworkManager) in some cases with systemd-networkd. In order to make this an easy transition, and to preserve compatibility with third party tools (for example, some from amazon), it's important that the traditional /etc/sysconfig/network-scripts/ifcfg-* files be supported. It's not necessary to be 100% feature compatible, just map the things which make sense, and then log a warning on unrecognized options (or possibly an error on _really_ unsupported options). Possibly some parameters should be mapped to "best fit" equivalent -- for example PERSISTENT_DHCLIENT might be mapped to CriticalConnection.
(In reply to Matthew Miller from comment #0) > We are interested in replacing the legacy initscripts network scripts (or > NetworkManager) in some cases with systemd-networkd. In order to make this > an easy transition, and to preserve compatibility with third party tools > (for example, some from amazon), it's important that the traditional > /etc/sysconfig/network-scripts/ifcfg-* files be supported. > > It's not necessary to be 100% feature compatible, just map the things which > make sense, and then log a warning on unrecognized options (or possibly an > error on _really_ unsupported options). Possibly some parameters should be > mapped to "best fit" equivalent -- for example PERSISTENT_DHCLIENT might be > mapped to CriticalConnection. As I mentioned there in the cloud tracker I think you guys are getting a bit ahead of yourself and should wait until the networkd code stabilizes a bit as well as for the work we would be doing in cleaning this up properly in a copr repo...
Reference to original discussion: https://fedorahosted.org/cloud/ticket/14 Such a generator should be simple to write. Not sure if it belongs upstream in networkd or downstream in Fedora, nor if this is something we want to encourage long-term though. Either way, I'm happy to review patches (would be best if someone who would actually use/test this would take the lead). As Johann mentioned in the original discussion, there is probably quite some missing functionality, but I'm happy to get an overview sooner rather than later on what you need in terms of features so don't see any reason not to start working on this right away. Btw, Matt, regarding dhclient and memory usage: systemd has its own dhcp(v4) client library, so networkd uses that rather than call out to an external daemon. I haven't looked much at memory usage recently, but if we are using a significant amount, please shout (as we sholud not).
(In reply to Tom Gundersen from comment #2) > Reference to original discussion: https://fedorahosted.org/cloud/ticket/14 > > Such a generator should be simple to write. Not sure if it belongs upstream > in networkd or downstream in Fedora, Given how many network implementation are out there as well as /etc/sysconfig/foo being Fedora/Red Hat ism, the network generator could crow quite large to support all the distro's uses cases and implementation, if that generate would be upstream hence I suggest distribution should carry their own. > nor if this is something we want to > encourage long-term though. I would think not and based on my experience doing so hinders perception thus adoption of systemd's own terminology as well as it being a new technology ( most recent case in point people think systemd time should behave as, as well as being complete cron replacement when in fact they are two completely different things which end up complementing each other ). An well defined roadmap how long upstream carry's backward compatibility/legacy support might be best >Either way, I'm happy to review patches (would > be best if someone who would actually use/test this would take the lead). > > As Johann mentioned in the original discussion, there is probably quite some > missing functionality, but I'm happy to get an overview sooner rather than > later on what you need in terms of features so don't see any reason not to > start working on this right away. I would say we should not integrate this into the distribution until we can satisfy all the core/base embedded/cloud/container/server use cases, then again I'm much more conservative how this gets implement then most people, ( with cloud WG this ends up just being half implement at best ) at one point I need to start learning not to care...
(In reply to Tom Gundersen from comment #2) > Btw, Matt, regarding dhclient and memory usage: systemd has its own dhcp(v4) > client library, so networkd uses that rather than call out to an external > daemon. I haven't looked much at memory usage recently, but if we are using > a significant amount, please shout (as we sholud not). Yeah, that's an interesting question: % ps -o vsz,rss,command 15479 6945 VSZ RSS COMMAND 10084 3588 dhclient eth0 15572 1228 systemd-networkd This looks rather favorable. (isc-dhcp-client 4.2.2.dfsg.1-5+de amd64 and systemd built from git with -O0 -g).
(In reply to Jóhann B. Guðmundsson from comment #3) > (In reply to Tom Gundersen from comment #2) > > As Johann mentioned in the original discussion, there is probably quite some > > missing functionality, but I'm happy to get an overview sooner rather than > > later on what you need in terms of features so don't see any reason not to > > start working on this right away. > > I would say we should not integrate this into the distribution until we can > satisfy all the core/base embedded/cloud/container/server use cases, then > again I'm much more conservative how this gets implement then most people, ( > with cloud WG this ends up just being half implement at best ) at one point > I need to start learning not to care... Not sure I could parse this part of your reply. To reiterate, my take is that at the moment what I think makes a lot of sense is to get a clear overview of the features that would be needed (and then sort out what is already there, what is on the TODO, and what will not be supported). Probably the best way to do this would be for someone with a stake in this to start working on a generator. Whether and when this sholud be integrated into the distribution I think is a separate discussion (which probably would make more sense when we know where we stand feature-wise).
I also think that including the generator upstream doesn't do any harm and may even be more practical as there can be more generators using other formats.
(In reply to Pavel Šimerda (pavlix) from comment #6) > I also think that including the generator upstream doesn't do any harm and > may even be more practical as there can be more generators using other > formats. I would argue not since there are so many different network implementation between distributions so upstream winds up to be carrying 5 - 10 different types of generator or a single one trying to support all of them. If it was up to me ( which is not ) any kind of distributions legacy support should be carried and maintained downstream with them.
(In reply to Pavel Šimerda (pavlix) from comment #6) > I also think that including the generator upstream doesn't do any harm and > may even be more practical as there can be more generators using other > formats. Ifcgf file support, like any other distro-specific format, has no place in upstream systemd. We will only support the one native systemd format.
Yup, I agree with Jóhann and Kay, the code should not live upstream in systemd. Maybe as a separate package, or maybe in the initscripts repo, I don't really mind...
(In reply to Tom Gundersen from comment #9) > Yup, I agree with Jóhann and Kay, the code should not live upstream in > systemd. Maybe as a separate package, or maybe in the initscripts repo, I > don't really mind... I do believe the plan was to have a product specific fedora-release component where stuff like this could reside as well as any preset overwrites and other deviation the products might have.
It sounds fine to put a generator into initscripts.rpm, it could even just be implemented as a shell script. initscripts.rpm should just become an optional component though, which is not commonly installed. $ rpm -e initscripts error: Failed dependencies: initscripts is needed by (installed) vte291-0.37.0-2.fc21.x86_64 initscripts is needed by (installed) vte3-0.36.1-3.fc21.x86_64 https://bugzilla.redhat.com/show_bug.cgi?id=1068864
(In reply to Kay Sievers from comment #11) > It sounds fine to put a generator into initscripts.rpm, it could even just be > implemented as a shell script. Sounds good. > initscripts.rpm should just become an optional component though, which is not > commonly installed. > > $ rpm -e initscripts > error: Failed dependencies: > initscripts is needed by (installed) vte291-0.37.0-2.fc21.x86_64 > initscripts is needed by (installed) vte3-0.36.1-3.fc21.x86_64 On my rawhide install: # rpm -e initscripts error: Failed dependencies: initscripts >= 9.54 is needed by (installed) ppp-2.4.6-4.fc21.x86_64 initscripts is needed by (installed) dhclient-12:4.3.0-9.fc21.x86_64 ppp: https://bugzilla.redhat.com/show_bug.cgi?id=1098444 (just filed) dhclient: https://bugzilla.redhat.com/show_bug.cgi?id=1098172 (work in progress)
I think a separate package would be better than initscripts. Rationale: we're trying to deprecate initscripts. :)