Bug 1650342 - systemd-networkd support in RHEL 8
Summary: systemd-networkd support in RHEL 8
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemd
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1623566
TreeView+ depends on / blocked
 
Reported: 2018-11-15 22:09 UTC by Morten Stevens
Modified: 2020-01-28 06:19 UTC (History)
28 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-26 10:11:22 UTC
Type: Bug
Target Upstream Version:
riehecky: needinfo+


Attachments (Terms of Use)

Description Morten Stevens 2018-11-15 22:09:23 UTC
Description of problem:

RHEL 8 beta should support systemd-networkd since it's already shipped with RHEL 7.

Actually, there is no support for systemd-networkd?

Version-Release number of selected component (if applicable):

systemd-239-8.el8.x86_64

How reproducible:

Steps to Reproduce:
1. dnf provides networkctl
2. systemctl enable systemd-networkd

Actual results:

dnf provides networkctl

Last metadata expiration check: 0:05:31 ago on Thu 15 Nov 2018 10:58:58 PM CET.
Error: No Matches found

# systemctl enable systemd-networkd
Failed to enable unit: Unit file systemd-networkd.service does not exist.

# networkctl
bash: networkctl: command not found...


Expected results:

systemd-networkd should be available

Comment 1 Michal Sekletar 2018-11-16 09:37:05 UTC
(In reply to Morten Stevens from comment #0)

> RHEL 8 beta should support systemd-networkd since it's already shipped with
> RHEL 7.

In RHEL-7 we shipped it in Optional channel, hence it was not officially supported. We decided to remove it for a couple for reasons,
  * networkd is not mature enough and is somewhat poorly maintained upstream
  * networkd is still missing management interfaces (DBUS interface)
  * RHEL's default network configuration tool is NetworkManager and we didn't want to send mixed signals to users
  * RHEL-8 was supposed to be as small as possible in terms of packages
  * we didn't see too much networkd usage (even experimental) in RHEL-7

Comment 2 Robert Scheck 2018-11-25 21:47:30 UTC
Given we raised multiple GSS tickets for systemd-networkd for RHEL 7, that
were even only more or less handled by Red Hat, because it's not in the base
channel, we definitely want to see systemd-networkd in RHEL 8. Reasons are
quite simple: systemd-networkd is smaller than NetworkManager (which is just
bloated on packaging level when looking to dependencies), which perfectly
fine for semi-static simple network configurations in virtual machines or
containers, especially given the fact that network-scripts are now marked as
deprecated (which otherwise would also do the job perfectly). Honestly, the
lack of DBUS interface in systemd-networkd is not an issue for us (it even
fits with our expectation of simple semi-static network configurations).

Comment 3 Robert Scheck 2018-11-25 21:49:58 UTC
Cross-filed case 02260325 at the Red Hat customer portal.

Comment 4 Lukáš Nykrýn 2018-11-26 09:58:02 UTC
I am sorry, but we don't plan to include the systemd-networkd in rhel8.

The main reason is that rhel is a stable distribution and including multiple components that aims to do the same things basically doubles our testing scenarios.

In rhel7 we have custom shell scripts in initrd, initscripts, NetworkManager and systemd-networkd (in optional channel), that are able to set up a network connection. And that complicates the maintenance.

We have agreed that we want to standardise on NM in all the scenarios, so we plan to remove/deprecate all the other solutions.

For your setup, I would encourage you to look into the "configure-and-quit" option for NM.

Also, I don't agree with the claim that it has too many dependencies, just for my curiosity, I have installed a minimal container on F29 (systemd passwd dnf fedora-release vim-minimal) and try to add the NM. The only packages it installed were NetworkManager, NetworkManager-libnm, libndp and polkit-libs.

Comment 5 RHEL Program Management 2018-11-26 10:11:22 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 6 Robert Scheck 2018-11-26 15:47:27 UTC
I am sorry, but I hereby request reopening this request given comment #5
happened without any possibility for us for a business justification via GSS.

Comment 12 Phil 2019-03-13 13:08:43 UTC
I'd prefer to be able to decide for myself what kind of network configuration to use. NetworkManager may be great for desktops but I don't want it on my servers. I understand the need to reduce the amount of supported packages and to define a standard on how Redhat's customers should set up their network, though.
Is there maybe a way for Redhat of providing systemd-networkd via an unsupported channel for us die-hards?

Comment 13 Jan Synacek 2019-03-18 08:53:58 UTC
(In reply to Phil from comment #12)
> Is there maybe a way for Redhat of providing systemd-networkd via an
> unsupported channel for us die-hards?

Currently, no. I may create a copr build in the future, though, if the demand is high enough. Or, if you feel brave enough, it shouldn't be really hard to grab the source rpm, modify the spec file a bit and build it locally.

Comment 14 Fred F 2019-03-20 09:37:31 UTC
Programming network interfaces through DBUS/nmcli is super nasty in managed environments. With systemd-networkd you just drop a plaintext file in /etc, which is definitely what you want on a fully managed system.

I know that NetworkManager can also be partially configured through text files, but the text file "API" is not considered stable. If you guys don't want to support networkd officially please at least ship a rpm through an unsupported channel.

Comment 16 Jan Synacek 2019-03-28 11:39:25 UTC
An unofficial repository with unsupported packages with systemd-networkd enabled can be found at

http://people.redhat.com/~jsynacek/systemd/systemd-rebuild-networkd/rhel-8.dev-x86_64/

Comment 17 Zach Villers 2019-04-15 02:32:17 UTC
I'd be interested to know how many large installations use NetworkManager vs disabling it and using network scripts. If Network scripts are further deprecated in RHEL 8, I imagine there will be a slower transition. We run upwards of 9K servers at $work, mostly VMs and none of them have NetworkManager enabled (7.3-7.6).

Comment 18 Pat Riehecky 2019-04-24 13:27:42 UTC
I will echo some of the other thoughts here.

Our plan was to move from legacy network scripts to networkd.  We are not using NetworkManager at this time.

Comment 19 Kyle Walker 2019-07-30 19:38:58 UTC
@Zach Villers,

Would it be possible to provide some additional details as to why NetworkManager is not utilized? There has been a great deal of developmental efforts devoted to NetworkManager over the tail end of RHEL 6 and the entirety of RHEL 7. Most, if not all, use-cases that were known to be deficient have been addressed in that timeframe. If there are factors that block it's adoption in your environment, I would very much like to discuss it further. 


@Pat Riehecky,

Has your team evaluated the possibility of using NetworkManager? Similar to the feedback above, I would be very interested in relaying any particular issues that block your team from adopting to the applicable teams so that we can work to get them addressed.

Comment 20 Pat Riehecky 2019-07-30 20:00:05 UTC
We've got these areas where I feel networkd would be stronger than NetworkManager:

1) Generation of connection profiles from a config management system.

When building a connection from a template file, the format in /etc/sysconfig/network-scripts/etc is not really ideal.  I could drop the files in /etc/NetworkManager/system-connections/ but all my admins look in either /etc/sysconfig/network-scripts or /etc/systemd/network/

The UUID is a bit complicated.  I can easily generate one UUID that is persistent across config runs, but two or three starts to become bothersome.

2) systemctl integration.

The value add here is not just on the 'enable' or 'disable' but on the 'status' front.  I can easily use my native service monitoring tools to monitor the status of my network links.

My system will automatically report 'degraded' state from 'systemctl status' if I've got a disruption.

Comment 21 Lukáš Nykrýn 2019-08-01 07:18:03 UTC
(In reply to Pat Riehecky from comment #20)
> We've got these areas where I feel networkd would be stronger than
> NetworkManager:
> 
> 1) Generation of connection profiles from a config management system.
> 
This should not be an issue, if an ifcfg file is working with network-scripts, it will work with NM as well, so you can use the same things you have used for the old initscripts.

Comment 22 Fred F 2019-08-02 11:30:51 UTC
(In reply to Kyle Walker from comment #19)
> Would it be possible to provide some additional details as to why
> NetworkManager is not utilized?

Just like Pat mentioned the integration into configuration management systems is much cleaner and easier with systemd-networkd. Just dump some text files into a directory and be done with it. The documentation of networkd is also much better than for NM, especially when it comes to the format of configuration files.

Admins want config files, no "nmcli" calls or fiddling around with polkit ;)

Last but not least people might need to support multiple distributions with their configuration management systems. All of the major distributions ship with systemd by default so it's a logical assumption that systemd-networkd is available everywhere.

Comment 23 David Tardon 2019-08-05 07:41:07 UTC
(In reply to Fred F from comment #22)
> Last but not least people might need to support multiple distributions with
> their configuration management systems. All of the major distributions ship
> with systemd by default so it's a logical assumption that systemd-networkd
> is available everywhere.

It's not. Distributions ship with systemd *as PID 1* as default. That doesn't imply they must (or should) ship other--optional--components of the systemd *project* as well.

Comment 24 Phil 2019-08-05 08:57:23 UTC
(In reply to David Tardon from comment #23)
> That doesn't imply they must (or should) ship other--optional--components of
> the systemd *project* as well.

But still they do :)

Debian: https://packages.debian.org/buster/amd64/systemd/filelist

ArchLinux: https://www.archlinux.org/packages/core/x86_64/systemd/

OpenSUSE: https://software.opensuse.org/package/systemd
$ rpm -qlp systemd-234-lp151.25.7.x86_64.rpm | grep networkd$
/usr/lib/systemd/systemd-networkd

Gentoo: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/systemd/systemd-242-r6.ebuild#n462

Could you please clarify how systemd-networkd is more an "other--optional--component" than, for example, systemd-{logind,machined,hostnamed,…}?
Systemd's meson file shows all of them as an option.

Comment 25 Zach Villers 2019-08-06 11:25:38 UTC
(In reply to Kyle Walker from comment #19)
> @Zach Villers,
> 
> Would it be possible to provide some additional details as to why
> NetworkManager is not utilized? There has been a great deal of developmental
> efforts devoted to NetworkManager over the tail end of RHEL 6 and the
> entirety of RHEL 7. Most, if not all, use-cases that were known to be
> deficient have been addressed in that timeframe. If there are factors that
> block it's adoption in your environment, I would very much like to discuss
> it further. 
> 
> 

I don't have the full history, but in brief, the place I work still has the occasional RHEL 5 server running, alongside a healthy proportion of RHEL 6. I'll try to find out if NM was used at any point. Many folks have an 'if it aint broke' mentality. Couple that with using PXE Boot -> Ansible for physicals as well as VM templates that use network scripts, there's so much gravity for using text files to control configuration.

Comment 26 David Tardon 2019-08-07 08:11:40 UTC
(In reply to Phil from comment #24)
> (In reply to David Tardon from comment #23)
> > That doesn't imply they must (or should) ship other--optional--components of
> > the systemd *project* as well.
> 
> But still they do :)

So? They choose to do. RHEL 8 chooses to do not. That's what optional means...

> Could you please clarify how systemd-networkd is more an
> "other--optional--component" than, for example,
> systemd-{logind,machined,hostnamed,…}?
> Systemd's meson file shows all of them as an option.

Why should I? I've never claimed that. Again, optional means it's upon the discretion of the distro whether to ship it or not. And RHEL 8 chooses to not ship networkd and timesyncd (in favor of NM and chrony). The other optional components are shipped because no already-widely-used alternatives exist.

Comment 27 Lukáš Nykrýn 2019-08-07 08:48:19 UTC
> I don't have the full history, but in brief, the place I work still has the
> occasional RHEL 5 server running, alongside a healthy proportion of RHEL 6.
> I'll try to find out if NM was used at any point. Many folks have an 'if it
> aint broke' mentality. Couple that with using PXE Boot -> Ansible for
> physicals as well as VM templates that use network scripts, there's so much
> gravity for using text files to control configuration.

Again I would like to mention, that we try to provide backwards compatibility between NM and network scripts. So ifcfg files are supported under NM and in rhel8 we have even introduced ifup/ifdown wrappers around nmcli so you can still use that. If you have any ifcfg configuration files that works under old network script and don't under NM please tell us so.

(In reply to Phil from comment #24)
> (In reply to David Tardon from comment #23)
> > That doesn't imply they must (or should) ship other--optional--components of
> > the systemd *project* as well.
> 
> But still they do :)
> 

The difference between rhel and other distribution is that if we ship something in rhel we are committed to fixing issues there. From fedora we can see that networkd, could be a problematic component when it comes to bugs. Also providing an alternative to a tool doubles the number of scenarios where we need to do integration testing.

Comment 28 Phil 2019-08-07 08:58:54 UTC
(In reply to Lukáš Nykrýn from comment #27)
> The difference between rhel and other distribution is that if we ship
> something in rhel we are committed to fixing issues there.

Thanks for the clarification. Sounds reasonable to me.
Even though RH might have managed to make NM "usable" for automation/configuration management in EL8 I still dislike NM's general idea (for servers - for laptops NM is great). That means either I'll stick to the legacy network-scripts or build my own networkd-enabled systemd. I think I can live with both :)

Comment 29 Yanko Kaneti 2019-09-26 17:35:28 UTC
Stumbled on this yesterday while re-creating a CentOS 7 setup with 8. Ouch!

Couldn't you still build it but not ship it and leave the unsupported part somehow to CentOS?

I personally find it much more palatable for semi-static setups. It doesn't hurt that its smaller and does almost nothing by default.

Comment 30 Felix Schwarz 2019-10-17 09:58:46 UTC
As many here in this thread I like systemd-networkd better so I built a separate "systemd-networkd" package which is available via COPR: 
https://copr.fedorainfracloud.org/coprs/fschwarz/systemd-networkd/

Please note that I tested this only superficially and did not use this in production as I need adapt our ansible scripts to work with CentOS 8.  Maybe it helps someone here to build his/her own workaround.

Sorry for spamming this bug report - if you have comments/questions please use my github page.

Comment 31 Pat Riehecky 2019-10-21 18:28:42 UTC
Would someone be willing to build systemd-networkd for EPEL8?

Comment 32 Lukáš Nykrýn 2019-10-22 08:08:46 UTC
(In reply to Pat Riehecky from comment #31)
> Would someone be willing to build systemd-networkd for EPEL8?

That is a bit problematic, you can't have a same source package both in RHEL and EPEL.

Comment 33 Felix Schwarz 2019-10-22 08:47:50 UTC
(In reply to Lukáš Nykrýn from comment #32)
> (In reply to Pat Riehecky from comment #31)
> > Would someone be willing to build systemd-networkd for EPEL8?
> 
> That is a bit problematic, you can't have a same source package both in RHEL
> and EPEL.

Would you mind to add a few more details? I know that EPEL can not ship a "systemd" package but I assume Pat ment something like my COPR package which ships indeed the same systemd.tar.gz but has a different (rpm) name.
(I fear this may become off-topic so I'll try not to derail this bug report. Maybe it is better to continue the discussion about "providing systemd-networkd externally" (COPR, EPEL) in a different place?)

Comment 34 Neal Gompa 2019-10-25 04:49:21 UTC
(In reply to Felix Schwarz from comment #33)
> (In reply to Lukáš Nykrýn from comment #32)
> > (In reply to Pat Riehecky from comment #31)
> > > Would someone be willing to build systemd-networkd for EPEL8?
> > 
> > That is a bit problematic, you can't have a same source package both in RHEL
> > and EPEL.
> 
> Would you mind to add a few more details? I know that EPEL can not ship a
> "systemd" package but I assume Pat ment something like my COPR package which
> ships indeed the same systemd.tar.gz but has a different (rpm) name.

That would be very risky, given how sensitive the systemd code is... It would need to stay in sync with RHEL upstream very tightly for security fixes. IMO, it'd be much better if networkd was just enabled and shipped on RHEL 8...

Comment 35 Jaroslav Petráš 2019-11-27 19:01:59 UTC
> In rhel7 we have custom shell scripts in initrd, initscripts, NetworkManager and systemd-networkd (in optional channel), that are able to set up a network connection. And that complicates the maintenance.
Yes and to get rid of this mess the best approach in our setups was to 'systemctl disable network', 'systemctl disable NetworkManager' and 'systemctl enable systemd-networkd'. We are using systemd-networkd for simple setups like VMs networks where vPHY MAC has to match configured one, but also for complex setups like baremetal clusters nodes with multiple LACP and VLANs configs. It's simple, it's working and it doesn't mess with your already configured interfaces/adresses when you removed them from configuration (this behaviour is welcome in our env).

Until now we weren't forced to compile custom core packages but how I see it, there is no other choice. 

> The difference between rhel and other distribution is that if we ship something in rhel we are committed to fixing issues there.
This is the opposite of:
> In RHEL-7 we shipped it in Optional channel, hence it was not officially supported. We decided to remove it ...

So still, I don't understand why it was removed from Optional. Yeah I read the reasons in #1 but in my opinion there is only one relevant which is networkd maturity. About mixed signals stuff, IMHO it's not relevant to networkd presence in Optional repository when admin has to install and enable it by hand explicitly.

Comment 36 Sotir One 2019-12-05 23:05:06 UTC
This is outrageous. Personally, I have never had an NM system that doesn't drop packets every 2 minutes when it scans/tries to initialize unused interfaces.

No one wants to mess with nmcli if they don't have to. And the insane argument that NM is better supported than networkd! Just open the Arch Wiki pages for both and compare the troubleshooting sections.

If you had to choose between the two then you should have chosen networkd.

RHEL8 is definitely going down the wrong path. You have removed support for LSI RAID/HBA cards, you have removed networkd and who knows what other kind of functionality you are going to remove in the near future.

I am moving my clients and my own systems to more user friendly distributions from now on.

Comment 38 Robert Scheck 2020-01-08 21:19:47 UTC
Given Red Hat is obviously not interested in shipping systemd-networkd with RHEL 8, bug #1789146 is my package review request for systemd-networkd for EPEL 8. As I don't treat myself able to backport larger systemd-networkd bug or security fixes (like Red Hat is doing for systemd in general but likely except for systemd-networkd), the package shall stay in sync with the systemd-networkd version in Fedora (which also leads to new features); I would be grateful if interested folks have a look to it (I'm also looking for active co-maintainers if the package review passes).


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