Bug 1090090 - RFE: generator for systemd-networkd from ifcfg format files
Summary: RFE: generator for systemd-networkd from ifcfg format files
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukáš Nykrýn
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-22 14:30 UTC by Matthew Miller
Modified: 2022-07-21 08:45 UTC (History)
14 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-07-21 08:45:46 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Matthew Miller 2014-04-22 14:30:30 UTC
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.

Comment 1 Jóhann B. Guðmundsson 2014-04-22 17:14:56 UTC
(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...

Comment 2 Tom Gundersen 2014-04-22 20:29:06 UTC
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).

Comment 3 Jóhann B. Guðmundsson 2014-04-22 21:47:02 UTC
(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...

Comment 4 Zbigniew Jędrzejewski-Szmek 2014-04-23 01:24:26 UTC
(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).

Comment 5 Tom Gundersen 2014-05-12 20:04:01 UTC
(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).

Comment 6 Pavel Šimerda (pavlix) 2014-05-12 21:52:30 UTC
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.

Comment 7 Jóhann B. Guðmundsson 2014-05-13 09:38:39 UTC
(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.

Comment 8 Kay Sievers 2014-05-13 09:51:31 UTC
(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.

Comment 9 Tom Gundersen 2014-05-13 10:11:02 UTC
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...

Comment 10 Jóhann B. Guðmundsson 2014-05-15 16:16:25 UTC
(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.

Comment 11 Kay Sievers 2014-05-15 16:54:08 UTC
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

Comment 12 Pavel Šimerda (pavlix) 2014-05-16 08:23:19 UTC
(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)

Comment 13 Matthew Miller 2015-07-21 15:41:33 UTC
I think a separate package would be better than initscripts.  Rationale: we're trying to deprecate initscripts. :)


Note You need to log in before you can comment on or make changes to this bug.