(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

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).

Cross-filed case 02260325 at the Red Hat customer portal.

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.

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

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.

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?

(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.

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.

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/

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).

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.

@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.

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.

(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.

(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.

(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.

(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.

(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.

(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.

> 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.

(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 :)

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.

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.

Would someone be willing to build systemd-networkd for EPEL8?

(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.

(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?)

(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...

> 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.

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.

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).

systemd-networkd is now available in EPEL (https://fedoraproject.org/wiki/EPEL) as systemd-networkd package.

From my point of view it's sad to see that Red Hat still prefers to stick for servers/containers/IoT devices with its NetworkManager rather supporting systemd-networkd, but I guess for RHEL 8 the decision is unfortunately signed and sealed meanwhile?!

I could relate to the previous comment.  We run quite a huge number of tiny instances and containers and NetworkManager is just a complex monstrosity nobody wanted to touch/script.  The concept behind systemd-networkd is simple and elegant, so every single instance in our environment was using it to configure its networking.  It is quite amazing how RedHat is simply ignoring its userbase and is becoming another big corporation that pursuits its own agenda. :(  I would not even mention networkd-resolved (which was a nice small service to provide a better local resolver to the systemd enabled system), which is also gone with RHEL8, it seems.

I would like to retract my comment on systemd-resolved (it is there thankfully).

I do want to say in my experience that NetworkManager in el7 and el8 has been overall working great for my usage creating servers/routers/firewalls.  It is nice to be able to use nmtui for setting up bridges and some other options and such quickly with a text GUI if you don't recall the specific file option to use with old network-scripts.  Nmcli has been good in my experience for tweaks and maintenance.  I do recall not liking NetworkManager when I first tried it.  I think that was more about not liking change.  It was a net positive though because of the nmtui and nmcli which I ended up liking eventually.  I do wish nmtui had an option to apply changes in the GUI though like nmcli has instead of just activate and deactivate which would cause loss of connectivity for the deactivate.

The only issue I have ever had with NetworkManager was when there were changes in EL8 where if you mistakenly assigned a static route to the wrong interface in nmtui, it used to still assign it to the correct interface based on the via IP address somehow(EL7 I think had the same behavior).  There was a change though in one of the . releases for EL8 that fixed that bug(?) and assigned it to the interface device the route was assigned to.  Easy fix to move the route but it was a head scratcher at first

I do see where systemd-networkd would be nice for cloud VMs.  It appears CBL Mariner is another Linux distro to add to the list of using systemd-networkd by default which caught me off guard at first when I was experimenting with it as I am now used to NetworkManager/nmtui/nmcli.

configure-and-quit=true capability was removed as well from NetworkManager. It is possible to supply configure-and-quit=initrd in the command line, but RedHat doesn't supply a unit file for this scenario, unless I missed it