Discussion:
Deadlines
(too old to reply)
Adam Williamson
2014-02-19 20:04:14 UTC
Permalink
In case anyone missed it, FESCo's minutes have this:

"AGREED: FESCo expects the Tech specs/docs from working groups by
March 3rd at the latest"

So, we've been off meetings and stuff for three weeks now, we probably
should kick back into gear soon :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Stephen Gallagher
2014-02-20 12:13:55 UTC
Permalink
Post by Adam Williamson
"AGREED: FESCo expects the Tech specs/docs from working groups by
March 3rd at the latest"
So, we've been off meetings and stuff for three weeks now, we
probably should kick back into gear soon :)
Sorry folks, I've been offline for the last two weeks due to a death
in the family and haven't been able to drive this. Has any progress
been made in my absence off-list?
Adam Williamson
2014-02-20 18:12:46 UTC
Permalink
Post by Stephen Gallagher
Post by Adam Williamson
"AGREED: FESCo expects the Tech specs/docs from working groups by
March 3rd at the latest"
So, we've been off meetings and stuff for three weeks now, we
probably should kick back into gear soon :)
Sorry folks, I've been offline for the last two weeks due to a death
in the family and haven't been able to drive this. Has any progress
been made in my absence off-list?
Not hugely, no - I think we were all kind of waiting for you or someone
else to start driving :( Different sets of us showed up around meeting
time each week, I think, and we never quite had quorum.

I just saw the following pass by from Dan Williams on an RH internal
list, posting it here as I'm quite sure Dan wouldn't mind:

"You might install NetworkManager-config-server, which drops some
server-type config files into /etc/NetworkManager/conf.d that do things
like ignoring the carrier on all interfaces and ensuring NM never
creates the default DHCP connections that are useful on desktops. There
are other options in there, like making NM stop
touching /etc/resolv.conf if you know you never need to update it. See
"man NetworkManager.conf" for more details on all these options."

sounds like something we might want?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Stephen Gallagher
2014-02-20 18:24:29 UTC
Permalink
Post by Adam Williamson
Post by Stephen Gallagher
Post by Adam Williamson
"AGREED: FESCo expects the Tech specs/docs from working groups
by March 3rd at the latest"
So, we've been off meetings and stuff for three weeks now, we
probably should kick back into gear soon :)
Sorry folks, I've been offline for the last two weeks due to a
death in the family and haven't been able to drive this. Has any
progress been made in my absence off-list?
Not hugely, no - I think we were all kind of waiting for you or
someone else to start driving :( Different sets of us showed up
around meeting time each week, I think, and we never quite had
quorum.
I just saw the following pass by from Dan Williams on an RH
internal list, posting it here as I'm quite sure Dan wouldn't
"You might install NetworkManager-config-server, which drops some
server-type config files into /etc/NetworkManager/conf.d that do
things like ignoring the carrier on all interfaces and ensuring NM
never creates the default DHCP connections that are useful on
desktops. There are other options in there, like making NM stop
touching /etc/resolv.conf if you know you never need to update it.
See "man NetworkManager.conf" for more details on all these
options."
sounds like something we might want?
Very much so. This is something Dan and I talked about at DevConf,
actually. One of the things we'd probably want to do in each of the
various Products is break out our default configurations into a
subpackage that be pulled in by the respective Product release package
as a way to install differing defaults. NetworkManager was the
poster-child for this idea, though I expect there are plenty of other
services that could benefit from this as well.
David Timothy Strauss
2014-02-21 01:05:57 UTC
Permalink
Post by Adam Williamson
"You might install NetworkManager-config-server, which drops some
server-type config files into /etc/NetworkManager/conf.d that do things
like ignoring the carrier on all interfaces and ensuring NM never
creates the default DHCP connections that are useful on desktops. There
are other options in there, like making NM stop
touching /etc/resolv.conf if you know you never need to update it. See
"man NetworkManager.conf" for more details on all these options."
sounds like something we might want?
That's presuming Fedora Server will prefer NetworkManager over the new
systemd v209 network units, which are quickly reaching parity and have
some nice service integration capability.
Stephen Gallagher
2014-02-21 01:14:08 UTC
Permalink
On Thu, Feb 20, 2014 at 10:12 AM, Adam Williamson
Post by Adam Williamson
"You might install NetworkManager-config-server, which drops
some server-type config files into /etc/NetworkManager/conf.d
that do things like ignoring the carrier on all interfaces and
ensuring NM never creates the default DHCP connections that are
useful on desktops. There are other options in there, like
making NM stop touching /etc/resolv.conf if you know you never
need to update it. See "man NetworkManager.conf" for more
details on all these options."
sounds like something we might want?
That's presuming Fedora Server will prefer NetworkManager over the
new systemd v209 network units, which are quickly reaching parity
and have some nice service integration capability.
For the immediate future, I'd like to say that, yes, Fedora Server
will be supporting NetworkManager. This is in large part due to its
maturity and extremely powerful public D-BUS API. That's not to say
that networkd won't be an option in the future, but at this point in
time, I think we'll probably want to go with the known quantity.

Would you mind going into more detail about why you think we might
want to pick systemd network units, though? Last I had heard
(admittedly a while ago), there were no plans for it to support any of
the more complicated network setups like bridging and multipath, which
are pretty much showstoppers in my mind for a server.
Anthony Messina
2014-02-21 01:34:17 UTC
Permalink
Post by Stephen Gallagher
On Thu, Feb 20, 2014 at 10:12 AM, Adam Williamson
Post by Adam Williamson
"You might install NetworkManager-config-server, which drops
some server-type config files into /etc/NetworkManager/conf.d
that do things like ignoring the carrier on all interfaces and
ensuring NM never creates the default DHCP connections that are
useful on desktops. There are other options in there, like
making NM stop touching /etc/resolv.conf if you know you never
need to update it. See "man NetworkManager.conf" for more
details on all these options."
sounds like something we might want?
That's presuming Fedora Server will prefer NetworkManager over the
new systemd v209 network units, which are quickly reaching parity
and have some nice service integration capability.
For the immediate future, I'd like to say that, yes, Fedora Server
will be supporting NetworkManager. This is in large part due to its
maturity and extremely powerful public D-BUS API. That's not to say
that networkd won't be an option in the future, but at this point in
time, I think we'll probably want to go with the known quantity.
Would you mind going into more detail about why you think we might
want to pick systemd network units, though? Last I had heard
(admittedly a while ago), there were no plans for it to support any of
the more complicated network setups like bridging and multipath, which
are pretty much showstoppers in my mind for a server.
According to "[systemd-devel] [ANNOUNCE] systemd 209" [1], it looks like some
of the server-level options are available.

I would also like to see support for this as well.

-A

1. http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html
--
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140220/8dfea8d9/attachment.sig>
Reindl Harald
2014-02-21 08:29:25 UTC
Permalink
Post by Stephen Gallagher
Would you mind going into more detail about why you think we might
want to pick systemd network units, though?
because it is more lightweight compared to NM and already
there by sharing code with other services - i know nobody
who is running NM on a server
Post by Stephen Gallagher
Last I had heard
(admittedly a while ago), there were no plans for it to support any of
the more complicated network setups like bridging and multipath, which
are pretty much showstoppers in my mind for a server
type systemd-networkd leads to
http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html

DHCP

A boolean. When true, enables basic DHCPv4 support.
Address

A static IPv4 or IPv6 address and its prefix length, separated by a "/" character. The format of the address
must be as described in inet_pton(3) . This is a short-hand for an [Address] section only containing an Address key
(see below).
Gateway

The gateway address, which must be in the format described in inet_pton(3) . This is a short-hand for a [Route]
section only containing a Gateway key.
DNS

A DNS server address, which must be in the format described in inet_pton(3) .
Bridge

The name of the bridge to add the link to.
Bond

The name of the bond to add the link to.
VLAN

The name of a VLAN to create on the link. This option may be specified more than once.

even that german news article talks about bridges, VLAN and bonding
http://www.heise.de/open/meldung/Init-Plattform-Systemd-regelt-jetzt-Netzwerkverbindungen-2119141.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/af5bf58d/attachment-0001.sig>
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 13:29:35 UTC
Permalink
Post by Adam Williamson
sounds like something we might want?
I would say no since systemd networkd is the future for servers.

Network Manager should go away on server installs it never work properly
and nobody used it

JBG
Reindl Harald
2014-02-21 14:00:16 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Adam Williamson
sounds like something we might want?
I would say no since systemd networkd is the future for servers.
Network Manager should go away on server installs it never work properly and nobody used it
i agree here - NM is not the replacement for network.service on servers
it's not needed in case of statical configured network cards and
systemd-networkd promises to be a sane future replacement

http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html

it's also work to migrate network.service configurations dealing with
brdiges, VPN, routings and so on but it's tighter integrated in systemd
which over the long covers the basic operating system besides the kernel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/fd53260b/attachment.sig>
Colin Walters
2014-02-21 14:11:53 UTC
Permalink
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson
Post by &quot;Jóhann B. Guðmundsson&quot;
Network Manager should go away on server installs it never work properly
and nobody used it
No, you are wrong.

Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even
if all resources that are presently on NetworkManager were dropped
today and focused on networkd, we'd still need a long ongoing
investment in actively maintaining it both for the ongoing server case
*and* for the client case (GNOME is deeply invested in NM).







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/0026aed8/attachment.html>
Reindl Harald
2014-02-21 14:21:58 UTC
Permalink
Post by Colin Walters
Post by &quot;Jóhann B. Guðmundsson&quot;
Network Manager should go away on server installs it never work properly and nobody used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even if all resources that are presently on
NetworkManager were dropped today and focused on networkd, we'd still need a long ongoing investment in actively
maintaining it both for the ongoing server case *and* for the client case (GNOME is deeply invested in NM)
you missed the "on server installs"

so the question is valid in case we talk about *Fedora server*, F21 is delayed because
Fedora.next / Fedora products and so systemd-209 should not be the target for F21 and
even considered for F20 in it's release cycle after systemd-208 is not that bugfree

that RHEL7 defaults to NM is no argumentation for Fedora
systemd-209 simply was not available for RHEL7 target
the same as systemd was not for RHEL6 which uses hence upstart

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/5dd63794/attachment.sig>
Colin Walters
2014-02-21 14:35:07 UTC
Permalink
On Fri, Feb 21, 2014 at 9:21 AM, Reindl Harald <h.reindl at thelounge.net>
Post by Reindl Harald
you missed the "on server installs"
No, I didn't.
Post by Reindl Harald
that RHEL7 defaults to NM is no argumentation for Fedora
We can pretend they're separate things, but in reality...RHEL7 will act
as a powerful "center of gravity". For new features that will land in
key infrastructure such as libvirt, firewalld, and GNOME, all of these
will need to work with NM. Any development work that is possibly
earmarked for backporting to RHEL7 will need to work with NM.

Anyone can drop in, wave their hands and say "networkd is the future" -
but the reality is that the existing OSes and investment in them don't
just disappear when new code is written.

I personally still work on RHEL6 maintenance, even when I'm writing
*brand new* code in say glib, I look at whether it would work on RHEL6,
and take that under consideration.

Even just for servers, networkd would require Anaconda work, libvirt
work, and really some sort of transition code for existing config
files. The benefit would have to be *really good* to be worth the cost
of going back to having two network stacks.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/e0415fb4/attachment.html>
Simo Sorce
2014-02-21 15:13:18 UTC
Permalink
Post by Reindl Harald
Post by Colin Walters
Post by &quot;Jóhann B. Guðmundsson&quot;
Network Manager should go away on server installs it never work properly and nobody used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even if all resources that are presently on
NetworkManager were dropped today and focused on networkd, we'd still need a long ongoing investment in actively
maintaining it both for the ongoing server case *and* for the client case (GNOME is deeply invested in NM)
you missed the "on server installs"
so the question is valid in case we talk about *Fedora server*, F21 is delayed because
Fedora.next / Fedora products and so systemd-209 should not be the target for F21 and
even considered for F20 in it's release cycle after systemd-208 is not that bugfree
that RHEL7 defaults to NM is no argumentation for Fedora
systemd-209 simply was not available for RHEL7 target
the same as systemd was not for RHEL6 which uses hence upstart
We can look at systemd-networkd in a distant future when it will be
proven to do what a generic server install needs.
However its time is not now.

NM has been enhanced to work in a great many situations, it includes
comprehensive support for all the situations systemd-networkd started
supporting and many more. It has a comprehensive CLI, TUI and even GUI
interface for administration that is completely lacking in systemd and
it has been tested and improved for a long time.

It can be easily integrated with things like cockpit as it offers a
broad dbus API.

People are working on getting deep integration so that NM can provide
out of the box DNSSEC support for the whole system too (try to install
dnssec-trigger on your F20 machine now to get a taste of it).

Etc, etc...

I do not think systemd will reach that level of functionality (and
probably never should, it makes no sense to duplicate all this work).

Systemd-networkd will probably be usable in some specialized cases (like
getting network in network boot systems or other well defined and
confined situations) but is not a general purpose network management
tool now, so it shouldn't be our default choice at the moment.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Adam Williamson
2014-02-21 17:57:14 UTC
Permalink
Post by Reindl Harald
Post by Colin Walters
Post by &quot;Jóhann B. Guðmundsson&quot;
Network Manager should go away on server installs it never work properly and nobody used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even if all resources that are presently on
NetworkManager were dropped today and focused on networkd, we'd still need a long ongoing investment in actively
maintaining it both for the ongoing server case *and* for the client case (GNOME is deeply invested in NM)
you missed the "on server installs"
so the question is valid in case we talk about *Fedora server*, F21 is delayed because
Fedora.next / Fedora products and so systemd-209 should not be the target for F21 and
even considered for F20 in it's release cycle after systemd-208 is not that bugfree
that RHEL7 defaults to NM is no argumentation for Fedora
systemd-209 simply was not available for RHEL7 target
the same as systemd was not for RHEL6 which uses hence upstart
It's taken, what, 7-8 Fedora cycles, 3-4 years, and one entire RHEL
cycle for NetworkManager to be in a state where RH considers it
acceptable as a default for RHEL 7.

Why are we assuming systemd-networkd shows up and will be good enough
for us overnight? Has anyone who's saying it's The Future and we should
switch to it immediately even run it yet?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Reindl Harald
2014-02-21 18:06:50 UTC
Permalink
Post by Adam Williamson
Post by Reindl Harald
Post by Colin Walters
Post by &quot;Jóhann B. Guðmundsson&quot;
Network Manager should go away on server installs it never work properly and nobody used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager, and even if all resources that are presently on
NetworkManager were dropped today and focused on networkd, we'd still need a long ongoing investment in actively
maintaining it both for the ongoing server case *and* for the client case (GNOME is deeply invested in NM)
you missed the "on server installs"
so the question is valid in case we talk about *Fedora server*, F21 is delayed because
Fedora.next / Fedora products and so systemd-209 should not be the target for F21 and
even considered for F20 in it's release cycle after systemd-208 is not that bugfree
that RHEL7 defaults to NM is no argumentation for Fedora
systemd-209 simply was not available for RHEL7 target
the same as systemd was not for RHEL6 which uses hence upstart
It's taken, what, 7-8 Fedora cycles, 3-4 years, and one entire RHEL
cycle for NetworkManager to be in a state where RH considers it
acceptable as a default for RHEL 7.
fine - and that is why RHEL is irrelevant in the context
Post by Adam Williamson
Why are we assuming systemd-networkd shows up and will be good enough
for us overnight?
why not?

* nobody is porting "network.service" to a systemd-unit
* NM is a no-go for most people on servers i know (except Simon)
Post by Adam Williamson
Has anyone who's saying it's The Future and we should
switch to it immediately even run it yet?
dow w ehave a systemd-209 somewhere
frankly i can't await to start testing systemd-networkd and get rid of
systemd-208 on Fedora, things can only get better like with systemd-208

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/a8ae55cc/attachment.sig>
Adam Williamson
2014-02-21 18:09:15 UTC
Permalink
Post by Reindl Harald
Post by Adam Williamson
It's taken, what, 7-8 Fedora cycles, 3-4 years, and one entire RHEL
cycle for NetworkManager to be in a state where RH considers it
acceptable as a default for RHEL 7.
fine - and that is why RHEL is irrelevant in the context
I don't see how that follows.
Post by Reindl Harald
Post by Adam Williamson
Why are we assuming systemd-networkd shows up and will be good enough
for us overnight?
why not?
Er................are you serious?

I don't tend to deploy software on my servers because I'm just guessing
it'll work.
Post by Reindl Harald
* nobody is porting "network.service" to a systemd-unit
* NM is a no-go for most people on servers i know (except Simon)
I'd run it on mine if I was deploying them today. It's a lot better than
it used to be for server use. Which makes sense, because its initial
design focus was desktop use, and once that was in good shape, server
side was worked on.
Post by Reindl Harald
Post by Adam Williamson
Has anyone who's saying it's The Future and we should
switch to it immediately even run it yet?
dow w ehave a systemd-209 somewhere
http://koji.fedoraproject.org/koji/buildinfo?buildID=499417 - build
failed on ARM. But if you haven't even built it locally and tried it
yet...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Reindl Harald
2014-02-21 18:16:54 UTC
Permalink
Post by Adam Williamson
do we have a systemd-209 somewhere
http://koji.fedoraproject.org/koji/buildinfo?buildID=499417 - build
failed on ARM. But if you haven't even built it locally and tried it
yet...
that's not the point

* currently nobody knows details but many have qualified guesses
* systemd replaced much complexer things than network.service
* on 99 out of 100 servers you don't want more than network.service
* on 99 out of 100 servers you don't want the NM dependency-chain
* you have all the systemd code already in the system
* you can expect systemd controls systemd-networkd.service better than
the old fashinoed LSB network.service i expect it to work relieable
* we are talking about *future*

so you won't get people like me in a direction to accept NM at all
well, we had to suck systemd in F15 and survived
so *now* that we survived we want to have it finished
have systemd finished means no LSB/SysV-Init service on the system
the payback have NM instead network.service is not accepted

guess what happens the next few years

people running Fedora on static network interfaces and hate
NetworkManager as much someone can hate software will use it
anyways - the same people would even write there own ifup
systemd-units if "network.service" would get dropped without
a replacement which is not NM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/2cf6ef10/attachment.sig>
Simo Sorce
2014-02-21 18:36:58 UTC
Permalink
Post by Reindl Harald
Post by Adam Williamson
do we have a systemd-209 somewhere
http://koji.fedoraproject.org/koji/buildinfo?buildID=499417 - build
failed on ARM. But if you haven't even built it locally and tried it
yet...
that's not the point
* currently nobody knows details but many have qualified guesses
* systemd replaced much complexer things than network.service
* on 99 out of 100 servers you don't want more than network.service
* on 99 out of 100 servers you don't want the NM dependency-chain
* you have all the systemd code already in the system
* you can expect systemd controls systemd-networkd.service better than
the old fashinoed LSB network.service i expect it to work relieable
* we are talking about *future*
so you won't get people like me in a direction to accept NM at all
well, we had to suck systemd in F15 and survived
so *now* that we survived we want to have it finished
have systemd finished means no LSB/SysV-Init service on the system
the payback have NM instead network.service is not accepted
Let me correct you here, *you* do not accept it, and that is fine, you
can configure your system to use systemd-networkd, report on how it
works and in due time we can consider it to become a default for Fedora
Server.

but At *this* moment you do not even know if it will really work or not,
because it can't even be compiled for Fedora, so let's table for more
discussion in a 3 months or so, ok ?
Post by Reindl Harald
guess what happens the next few years
I do not have crystal balls.
Post by Reindl Harald
people running Fedora on static network interfaces and hate
NetworkManager as much someone can hate software will use it
anyways - the same people would even write there own ifup
systemd-units if "network.service" would get dropped without
a replacement which is not NM
This is the same argument people had against systemd.
People will hate it and won't know how to work w/o sysv.

Sorry I do not care for fear mongering, thank you.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Reindl Harald
2014-02-21 18:48:01 UTC
Permalink
Post by Simo Sorce
Post by Reindl Harald
Post by Adam Williamson
do we have a systemd-209 somewhere
http://koji.fedoraproject.org/koji/buildinfo?buildID=499417 - build
failed on ARM. But if you haven't even built it locally and tried it
yet...
that's not the point
* currently nobody knows details but many have qualified guesses
* systemd replaced much complexer things than network.service
* on 99 out of 100 servers you don't want more than network.service
* on 99 out of 100 servers you don't want the NM dependency-chain
* you have all the systemd code already in the system
* you can expect systemd controls systemd-networkd.service better than
the old fashinoed LSB network.service i expect it to work relieable
* we are talking about *future*
so you won't get people like me in a direction to accept NM at all
well, we had to suck systemd in F15 and survived
so *now* that we survived we want to have it finished
have systemd finished means no LSB/SysV-Init service on the system
the payback have NM instead network.service is not accepted
Let me correct you here, *you* do not accept it
not only i, but skip that details because it leads to a flamewar
Post by Simo Sorce
but At *this* moment you do not even know if it will really work or not,
because it can't even be compiled for Fedora
so let's table for more discussion in a 3 months or so, ok ?
agreed
Post by Simo Sorce
Post by Reindl Harald
guess what happens the next few years
I do not have crystal balls
in that context i do - NM will not be accepted for people
satisfied with a simple "ifcfg-eth0" the past, currently
and in the future
Post by Simo Sorce
Post by Reindl Harald
people running Fedora on static network interfaces and hate
NetworkManager as much someone can hate software will use it
anyways - the same people would even write there own ifup
systemd-units if "network.service" would get dropped without
a replacement which is not NM
This is the same argument people had against systemd.
People will hate it and won't know how to work w/o sysv.
the difference is that from F15 on it was *impossible* to stay
at SysvInit, otherwise i would have started use it with F16/F17
but given that that time back Fedora had outdated kernels not
supporting the onobrad-NIC of sandy-bridge machines at all and
the display froze all day long you needed to upgrade a fresh
installed F14 to F15 wihtout any choice
Post by Simo Sorce
Sorry I do not care for fear mongering, thank you
there is no fear

we need a lightweight replacement for network.service
maybe not now but in the to so far future and before someone claims
"network.service is no nolger maintained hust use NM"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/5875ed9c/attachment.sig>
Matthew Miller
2014-02-24 14:06:34 UTC
Permalink
Post by Reindl Harald
* systemd replaced much complexer things than network.service
Don't underestimate the complexity of the network startup scripts. There are
a lot of edge cases and weird conditions encoded the years of cruft that has
built up around the shell scripts and surely in networkmanager as well. I'm
sure networkd will handle the simple cases nicely, but experience indicates
that it'll be several years before all of the non-obvious problems get
ironed out -- things which looked trivial to deal with in the rewrite but
which actually have a gotcha.
--
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>
Reindl Harald
2014-02-24 14:08:50 UTC
Permalink
Post by Matthew Miller
Post by Reindl Harald
* systemd replaced much complexer things than network.service
Don't underestimate the complexity of the network startup scripts. There are
a lot of edge cases and weird conditions encoded the years of cruft that has
built up around the shell scripts and surely in networkmanager as well. I'm
sure networkd will handle the simple cases nicely, but experience indicates
that it'll be several years before all of the non-obvious problems get
ironed out -- things which looked trivial to deal with in the rewrite but
which actually have a gotcha
i did not said anything else

but to replace network.service on machines with one or two interface
and a static IP on them with no further magic it's the more lightweight
one than NetworkManager

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140224/1e421554/attachment-0001.sig>
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 15:00:44 UTC
Permalink
Post by Colin Walters
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson
Post by &quot;Jóhann B. Guðmundsson&quot;
Network Manager should go away on server installs it never work
properly and nobody used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager
This is Fedora not RHEL

JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/0495a65e/attachment.html>
Simo Sorce
2014-02-21 15:16:23 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Colin Walters
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson
Post by &quot;Jóhann B. Guðmundsson&quot;
Network Manager should go away on server installs it never work
properly and nobody used it
No, you are wrong.
Red Hat Enterprise Linux 7(.0) will default to NetworkManager
This is Fedora not RHEL
What Colin meant is that because of RHEL the NetworkManager team has
done a lot of work for the Server case and NM is currently in a better
position to be used for Servers.

It has a funded team to work on it and to care for Server specific
cases.

The systemd-networkd support, at the moment, is a limited tool for some
special cases and arguably should remain just that.

So at the moment NM is the best technical choice for us too.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 15:19:21 UTC
Permalink
Post by Simo Sorce
What Colin meant is that because of RHEL the NetworkManager team has
done a lot of work for the Server case and NM is currently in a better
position to be used for Servers.
No it's not
Post by Simo Sorce
It has a funded team to work on it and to care for Server specific
cases.
Irrelevant to Fedora and perhaps RH should start re-allocating resources
to networkd
Post by Simo Sorce
The systemd-networkd support, at the moment, is a limited tool for some
special cases and arguably should remain just that.
So at the moment NM is the best technical choice for us too.
I thought the .next and wg effort was aiming for the "future" not basing
itself on to be obsoleted technology.

Networkd is going to be providing the network infrastructure for
embedded/server

JBG
Simo Sorce
2014-02-21 15:33:06 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
What Colin meant is that because of RHEL the NetworkManager team has
done a lot of work for the Server case and NM is currently in a better
position to be used for Servers.
No it's not
Without qualification I will treat this statement as meaningless and
ignore it.
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
It has a funded team to work on it and to care for Server specific
cases.
Irrelevant to Fedora and perhaps RH should start re-allocating resources
to networkd
It is very relevant to Fedora which upstream projects are funded and for
what work, because Fedora does not do very much Upstream work, it is a
downstream from this POV.

I appreciate you like systemd-networkd however *that* doesn't matter.
Right now NM is a better technical choice.
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
The systemd-networkd support, at the moment, is a limited tool for some
special cases and arguably should remain just that.
So at the moment NM is the best technical choice for us too.
I thought the .next and wg effort was aiming for the "future" not basing
itself on to be obsoleted technology.
Well before you declare NM as "obsolete" you need to prove that it is.
Post by &quot;Jóhann B. Guðmundsson&quot;
Networkd is going to be providing the network infrastructure for
embedded/server
at the moment Networkd can be classified as "immature", so it can be the
basis for a Fedora Server. Once that situation will change we can
certainly revisit this.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 15:57:24 UTC
Permalink
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
It has a funded team to work on it and to care for Server specific
cases.
Irrelevant to Fedora and perhaps RH should start re-allocating resources
to networkd
It is very relevant to Fedora which upstream projects are funded and for
what work, because Fedora does not do very much Upstream work, it is a
downstream from this POV.
Care to clarify that statement as in how is this more relevant to Fedora
as opposed to any other downstreams that package and ship NM and any
other project for that matter.
Post by Simo Sorce
I appreciate you like systemd-networkd however *that* doesn't matter.
Right now NM is a better technical choice.
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
The systemd-networkd support, at the moment, is a limited tool for some
special cases and arguably should remain just that.
So at the moment NM is the best technical choice for us too.
I thought the .next and wg effort was aiming for the "future" not basing
itself on to be obsoleted technology.
Well before you declare NM as "obsolete" you need to prove that it is.
Like is being done with openlmi and cockpit compared to everything that
exist out there.
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Networkd is going to be providing the network infrastructure for
embedded/server
at the moment Networkd can be classified as "immature", so it can be the
basis for a Fedora Server. Once that situation will change we can
certainly revisit this.
And openlmi and cockpit are considered being mature?

JBG
Stephen Gallagher
2014-02-21 16:12:48 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
It has a funded team to work on it and to care for Server
specific cases.
Irrelevant to Fedora and perhaps RH should start re-allocating
resources to networkd
It is very relevant to Fedora which upstream projects are funded
and for what work, because Fedora does not do very much Upstream
work, it is a downstream from this POV.
Care to clarify that statement as in how is this more relevant to
Fedora as opposed to any other downstreams that package and ship NM
and any other project for that matter.
Post by Simo Sorce
I appreciate you like systemd-networkd however *that* doesn't
matter. Right now NM is a better technical choice.
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
The systemd-networkd support, at the moment, is a limited
tool for some special cases and arguably should remain just
that.
So at the moment NM is the best technical choice for us too.
I thought the .next and wg effort was aiming for the "future"
not basing itself on to be obsoleted technology.
Well before you declare NM as "obsolete" you need to prove that it is.
Like is being done with openlmi and cockpit compared to everything
that exist out there.
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Networkd is going to be providing the network infrastructure
for embedded/server
at the moment Networkd can be classified as "immature", so it can
be the basis for a Fedora Server. Once that situation will change
we can certainly revisit this.
And openlmi and cockpit are considered being mature?
Different layering levels. Cockpit and OpenLMI are technologies that
provide a useful high-level view into the system. If they have bugs or
are broken, there are plenty of low-level fallbacks (such as SSH and
config file mangling) that can take their place. The networking stack
is fundamental plumbing and should therefore be treated with more care.

I'm not against investigating networkd as a future solution for Fedora
Server. I think it has a lot of potential. Unfortunately, right now
it's "immature" in the sense that it doesn't even build in Fedora
because it lacks support on some architectures[1]. That's a
non-starter in my opinion.

[1]
http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html
Colin Walters
2014-02-21 16:11:47 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
And openlmi and cockpit are considered being mature?
They're not attempting to replace existing functionality - they're
conceptually addons on top of a core. With Cockpit you are definitely
expected to still use ssh, for example.
Simo Sorce
2014-02-21 16:19:57 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
It has a funded team to work on it and to care for Server specific
cases.
Irrelevant to Fedora and perhaps RH should start re-allocating resources
to networkd
It is very relevant to Fedora which upstream projects are funded and for
what work, because Fedora does not do very much Upstream work, it is a
downstream from this POV.
Care to clarify that statement as in how is this more relevant to Fedora
as opposed to any other downstreams that package and ship NM and any
other project for that matter.
It is as relevant to Fedora as to any other distribution.

*you* said "Irrelevant to Fedora" and I said it is not true, what else
do you need ?
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
I appreciate you like systemd-networkd however *that* doesn't matter.
Right now NM is a better technical choice.
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
The systemd-networkd support, at the moment, is a limited tool for some
special cases and arguably should remain just that.
So at the moment NM is the best technical choice for us too.
I thought the .next and wg effort was aiming for the "future" not basing
itself on to be obsoleted technology.
Well before you declare NM as "obsolete" you need to prove that it is.
Like is being done with openlmi and cockpit compared to everything that
exist out there.
I do not understand this statement, but it sounds like a strawman, so I
will just ignore it for now.
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Networkd is going to be providing the network infrastructure for
embedded/server
at the moment Networkd can be classified as "immature", so it can be the
basis for a Fedora Server. Once that situation will change we can
certainly revisit this.
And openlmi and cockpit are considered being mature?
Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
replace working, mature, available software.

Please stick to valid arguments or avoid trolling (yes I said trolling,
this last paragraph clearly is, as it draws in stuff that has nothing to
do with the conversation at hand).

Simo.
--
Simo Sorce * Red Hat, Inc * New York
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 16:47:39 UTC
Permalink
Post by Simo Sorce
Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
replace working, mature, available software.
Relevant in the way that you dont need NM to configure "enterprise" (
bridging/bonding etc ) networking so maturity in NM is irrelevant I
would say.

JBG
Simo Sorce
2014-02-21 17:01:00 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
replace working, mature, available software.
Relevant in the way that you dont need NM to configure "enterprise" (
bridging/bonding etc ) networking so maturity in NM is irrelevant I
would say.
Ok, can you tell me how do you configure Team Bonding or IP over
Infiniband with systemd-networkd ?

Simo.
--
Simo Sorce * Red Hat, Inc * New York
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 18:08:57 UTC
Permalink
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
replace working, mature, available software.
Relevant in the way that you dont need NM to configure "enterprise" (
bridging/bonding etc ) networking so maturity in NM is irrelevant I
would say.
Ok, can you tell me how do you configure Team Bonding or IP over
Infiniband with systemd-networkd ?
systemd-networkd supports configuring local network interfaces
statically or via DHCP as well as being capable of bringing up bridges,
VLANs, and bonding if that's what you are wondering and you configure
those by creating .netdev file and define which you want with kind= as in
foo.netdev
[NetDev]
Name=$bar
Kind=bond/bridge/vlan

Then you go about creating relevant related .link and .network units
just watch out that it wont collide with ethXYZ namespace used by the kernel
IPoIB is not supported at this moment and you did not need NM to do that
anyway just like the rest so...

JBG
Simo Sorce
2014-02-21 18:33:16 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
Irrelevant strawman, nobody is proposing to use openlmi or cockpit to
replace working, mature, available software.
Relevant in the way that you dont need NM to configure "enterprise" (
bridging/bonding etc ) networking so maturity in NM is irrelevant I
would say.
Ok, can you tell me how do you configure Team Bonding or IP over
Infiniband with systemd-networkd ?
systemd-networkd supports configuring local network interfaces
statically or via DHCP as well as being capable of bringing up bridges,
VLANs, and bonding if that's what you are wondering and you configure
those by creating .netdev file and define which you want with kind= as in
foo.netdev
[NetDev]
Name=$bar
Kind=bond/bridge/vlan
Then you go about creating relevant related .link and .network units
just watch out that it wont collide with ethXYZ namespace used by the kernel
IPoIB is not supported at this moment and you did not need NM to do that
anyway just like the rest so...
Ok so your answer boils down to:
"I do not know how to do that, but here is a blurb taken from the
general FAQ about how to configure something (but not what was asked)."

This is apparently sufficient to declare systemd-networkd done and ready
for Fedora Server ... OK!

Excuse me if I am a bit skeptical, and will ignore further arguments on
this for the time being.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 19:04:12 UTC
Permalink
Post by Simo Sorce
"I do not know how to do that, but here is a blurb taken from the
general FAQ about how to configure something (but not what was asked)."
You are one piece of work when someone responds to you.

JBG
Simo Sorce
2014-02-21 19:29:49 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
"I do not know how to do that, but here is a blurb taken from the
general FAQ about how to configure something (but not what was asked)."
You are one piece of work when someone responds to you.
I guess I'll take that as a compliment.

Thanks you :-)

Simo.
--
Simo Sorce * Red Hat, Inc * New York
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 19:33:57 UTC
Permalink
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
"I do not know how to do that, but here is a blurb taken from the
general FAQ about how to configure something (but not what was asked)."
You are one piece of work when someone responds to you.
I guess I'll take that as a compliment.
It was not meant as such but you not figuring that out comes of as no
surprise to me :)

JBG
Stephen Gallagher
2014-02-21 19:38:57 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
Post by Simo Sorce
Ok so your answer boils down to: "I do not know how to do
that, but here is a blurb taken from the general FAQ
about how to configure something (but not what was
asked)."
You are one piece of work when someone responds to you.
I guess I'll take that as a compliment.
It was not meant as such but you not figuring that out comes of as
no surprise to me :)
This branch of the thread is closed.

I remind people to please consult
http://fedoraproject.org/code-of-conduct before posting.
Reindl Harald
2014-02-21 19:38:24 UTC
Permalink
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Simo Sorce
"I do not know how to do that, but here is a blurb taken from the
general FAQ about how to configure something (but not what was asked)."
You are one piece of work when someone responds to you.
I guess I'll take that as a compliment.
It was not meant as such but you not figuring that out comes of as no surprise to me :)
please stop that
thank you!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/e63d5d61/attachment.sig>
Colin Walters
2014-02-21 15:26:24 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
This is Fedora not RHEL
Since Fedora is the upstream for Red Hat Enterprise Linux, there needs
to be a mechanism by which feedback can be provided from downstream to
upstream.

I am using this mailing list as that mechanism.
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 15:25:52 UTC
Permalink
Post by Colin Walters
Post by &quot;Jóhann B. Guðmundsson&quot;
This is Fedora not RHEL
Since Fedora is the upstream for Red Hat Enterprise Linux, there needs
to be a mechanism by which feedback can be provided from downstream to
upstream.
I am using this mailing list as that mechanism.
RHEL and it's needs should not dictate and decide the direction of
Fedora and as soon as it does Fedora stops being "sponsored" project...

JBG
Colin Walters
2014-02-21 15:34:20 UTC
Permalink
Hi Jóhann,
Post by &quot;Jóhann B. Guðmundsson&quot;
RHEL and it's needs should not dictate and decide the direction of
Fedora and as soon as it does Fedora stops being "sponsored" project...
I think an objective read of my communication thus far would show that I
personally am not trying to dictate and decide (or am I seeing anyone
else do so) but to have a *conversation*.

You can't seriously have expected to be able to drop in and say
"networkd is the future!" and have everyone nod their head silently...
Networking is a very complex topic.

Did you know for example that Microsoft has done some research on using
wireless in data centers? Yes, really:

http://research.microsoft.com/pubs/157700/flyways_sigcomm11.pdf
&quot;Jóhann B. Guðmundsson&quot;
2014-02-21 16:00:56 UTC
Permalink
Post by Colin Walters
You can't seriously have expected to be able to drop in and say
"networkd is the future!" and have everyone nod their head silently...
Networking is a very complex topic.
Does not change the fact that networkd is replacing the legacy network
initscript and it's purpose as well as few things else so networkd is
the future and shipping multiple networking solution for
embedded/servers/cloud/containers makes no sense.

I would not be surprised that networkd will be ready enough for
replacement in F22

JBG
Colin Walters
2014-02-21 16:09:47 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
I would not be surprised that networkd will be ready enough for
replacement in F22
If you're saying the goal is for networkd to kill off network.service
entirely - then I'm definitely in favor of that. I think that's only
realistic though if there were a parser for the old RH ifconfig files to
translate to networkd.

Anyways, there are other sides to this discussion - I'm very hopeful
that the DHCP client library work inside networkd can be reused by
NetworkManager for example.

But do also expect some cool stuff from the NM side - for example, the
kdbus work should allow it to finally exit when unused if you just have
say a static IP, without race conditions.
Matthew Miller
2014-02-24 14:08:33 UTC
Permalink
Post by Colin Walters
But do also expect some cool stuff from the NM side - for example, the
kdbus work should allow it to finally exit when unused if you just have
say a static IP, without race conditions.
And I will be very happy. https://bugzilla.redhat.com/show_bug.cgi?id=863515
:)
--
Matthew Miller -- Fedora Project -- <mattdm at fedoraproject.org>
Simo Sorce
2014-02-21 16:16:20 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Colin Walters
You can't seriously have expected to be able to drop in and say
"networkd is the future!" and have everyone nod their head silently...
Networking is a very complex topic.
Does not change the fact that networkd is replacing the legacy network
initscript and it's purpose as well as few things else so networkd is
the future and shipping multiple networking solution for
embedded/servers/cloud/containers makes no sense.
I would not be surprised that networkd will be ready enough for
replacement in F22
Maybe you should go and check what NM can do today before writing it off
or before thinking systemd-networkd will be mature in the short term.

There is a very good reason why it took time for NM to become really
usable on servers, and that's because exotic network configurations are
fiendishly difficult to describe and manage.
And the exotic configurations are found on servers.

So by all means, let's watch what happens with systemd-networkd, but at
the moment it is not something I would base my work on.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Reindl Harald
2014-02-21 16:36:09 UTC
Permalink
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Colin Walters
You can't seriously have expected to be able to drop in and say
"networkd is the future!" and have everyone nod their head silently...
Networking is a very complex topic.
Does not change the fact that networkd is replacing the legacy network
initscript and it's purpose as well as few things else so networkd is
the future and shipping multiple networking solution for
embedded/servers/cloud/containers makes no sense.
I would not be surprised that networkd will be ready enough for
replacement in F22
Maybe you should go and check what NM can do today before writing it off
or before thinking systemd-networkd will be mature in the short term
nobody said replace NM everywhere

* replace network.service is the topic
* nobody i know is using NM on servers
* they all continue to use LSB network.service for good reasons

you do not need a complex software like NM on a server with one
or two static configured ethernet cards and nothing else
________________________________________________

go away with all that dependencies on my servers

Installing:
NetworkManager
Installing for dependencies:
ModemManager-glib
NetworkManager-glib
avahi-autoipd
libndp
libnl3
ppp
wpa_supplicant
________________________________________________

go away with all the dependencies on my full featured workstation
running BIND as nameserver, hostapd with 2 instances and a own
DHCP server for both, OpenVPN, httpd, dbmail, MariaDB and what not
all or network services, firewalls and routings

Installing:
NetworkManager
Installing for dependencies:
ModemManager-glib
avahi-autoipd
dnsmasq
libndp
ppp
wpa_supplicant

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140221/5ee37655/attachment-0001.sig>
Simo Sorce
2014-02-21 16:51:55 UTC
Permalink
Post by Reindl Harald
Post by Simo Sorce
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Colin Walters
You can't seriously have expected to be able to drop in and say
"networkd is the future!" and have everyone nod their head silently...
Networking is a very complex topic.
Does not change the fact that networkd is replacing the legacy network
initscript and it's purpose as well as few things else so networkd is
the future and shipping multiple networking solution for
embedded/servers/cloud/containers makes no sense.
I would not be surprised that networkd will be ready enough for
replacement in F22
Maybe you should go and check what NM can do today before writing it off
or before thinking systemd-networkd will be mature in the short term
nobody said replace NM everywhere
* replace network.service is the topic
* nobody i know is using NM on servers
Hello my name is Simo.
Now you know someone who does :)
Post by Reindl Harald
* they all continue to use LSB network.service for good reasons
you do not need a complex software like NM on a server with one
or two static configured ethernet cards and nothing else
________________________________________________
go away with all that dependencies on my servers
NetworkManager
ModemManager-glib
NetworkManager-glib
avahi-autoipd
libndp
libnl3
ppp
wpa_supplicant
________________________________________________
go away with all the dependencies on my full featured workstation
running BIND as nameserver, hostapd with 2 instances and a own
DHCP server for both, OpenVPN, httpd, dbmail, MariaDB and what not
all or network services, firewalls and routings
NetworkManager
ModemManager-glib
avahi-autoipd
dnsmasq
libndp
ppp
wpa_supplicant
We can look into whether these dependencies are excessive or not,
orwhether they can be made conditional instead of hard, for the people
that want minimal installs.
I do not think this is necessarily a bit problem.

Simo.
--
Simo Sorce * Red Hat, Inc * New York
Loading...