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 :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/19/2014 03:04 PM, Adam Williamson wrote:
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 :)
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?
On Thu, 2014-02-20 at 07:13 -0500, Stephen Gallagher wrote:
On 02/19/2014 03:04 PM, Adam Williamson wrote:
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 :)
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?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/20/2014 01:12 PM, Adam Williamson wrote:
On Thu, 2014-02-20 at 07:13 -0500, Stephen Gallagher wrote:
On 02/19/2014 03:04 PM, Adam Williamson wrote:
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 :)
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?
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.
On Thu, Feb 20, 2014 at 10:12 AM, Adam Williamson awilliam@redhat.com wrote:
"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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/20/2014 08:05 PM, David Timothy Strauss wrote:
On Thu, Feb 20, 2014 at 10:12 AM, Adam Williamson awilliam@redhat.com wrote:
"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.
On Thursday, February 20, 2014 08:14:08 PM Stephen Gallagher wrote:
On 02/20/2014 08:05 PM, David Timothy Strauss wrote:
On Thu, Feb 20, 2014 at 10:12 AM, Adam Williamson
awilliam@redhat.com wrote:
"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.htm...
Am 21.02.2014 02:14, schrieb 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
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.htm...
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-Netzwer...
Am 21.02.2014 14:29, schrieb Jóhann B. Guðmundsson:
On 02/20/2014 06:12 PM, Adam Williamson wrote:
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.htm...
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
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
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).
Am 21.02.2014 15:11, schrieb Colin Walters:
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
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
On Fri, Feb 21, 2014 at 9:21 AM, Reindl Harald h.reindl@thelounge.net wrote:
you missed the "on server installs"
No, I didn't.
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.
On Fri, 2014-02-21 at 15:21 +0100, Reindl Harald wrote:
Am 21.02.2014 15:11, schrieb Colin Walters:
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
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.
On Fri, 2014-02-21 at 15:21 +0100, Reindl Harald wrote:
Am 21.02.2014 15:11, schrieb Colin Walters:
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
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?
Am 21.02.2014 18:57, schrieb Adam Williamson:
On Fri, 2014-02-21 at 15:21 +0100, Reindl Harald wrote:
Am 21.02.2014 15:11, schrieb Colin Walters:
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
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
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)
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
On Fri, 2014-02-21 at 19:06 +0100, Reindl Harald wrote:
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.
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.
- 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.
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...
Am 21.02.2014 19:09, schrieb Adam Williamson:
On Fri, 2014-02-21 at 19:06 +0100, Reindl Harald wrote:
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
On Fri, 2014-02-21 at 19:16 +0100, Reindl Harald wrote:
Am 21.02.2014 19:09, schrieb Adam Williamson:
On Fri, 2014-02-21 at 19:06 +0100, Reindl Harald wrote:
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 ?
guess what happens the next few years
I do not have crystal balls.
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.
Am 21.02.2014 19:36, schrieb Simo Sorce:
On Fri, 2014-02-21 at 19:16 +0100, Reindl Harald wrote:
Am 21.02.2014 19:09, schrieb Adam Williamson:
On Fri, 2014-02-21 at 19:06 +0100, Reindl Harald wrote:
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
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
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
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
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"
On Fri, Feb 21, 2014 at 07:16:54PM +0100, Reindl Harald wrote:
- 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.
Am 24.02.2014 15:06, schrieb Matthew Miller:
On Fri, Feb 21, 2014 at 07:16:54PM +0100, Reindl Harald wrote:
- 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
On 02/21/2014 02:11 PM, Colin Walters wrote:
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
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
On Fri, 2014-02-21 at 15:00 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 02:11 PM, Colin Walters wrote:
On Fri, Feb 21, 2014 at 8:29 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
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.
On 02/21/2014 03:16 PM, Simo Sorce wrote:
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
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
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
On Fri, 2014-02-21 at 15:19 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:16 PM, Simo Sorce wrote:
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.
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.
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.
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.
On 02/21/2014 03:33 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 15:19 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:16 PM, Simo Sorce wrote:
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.
I appreciate you like systemd-networkd however *that* doesn't matter. Right now NM is a better technical choice.
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.
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
On Fri, 2014-02-21 at 15:57 +0000, "Jóhann B. Guðmundsson" wrote:
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/21/2014 10:57 AM, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:33 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 15:19 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:16 PM, Simo Sorce wrote:
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.
I appreciate you like systemd-networkd however *that* doesn't matter. Right now NM is a better technical choice.
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.
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.htm...
On Fri, 2014-02-21 at 15:57 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:33 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 15:19 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:16 PM, Simo Sorce wrote:
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 ?
I appreciate you like systemd-networkd however *that* doesn't matter. Right now NM is a better technical choice.
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.
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.
On 02/21/2014 04:19 PM, Simo Sorce wrote:
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
On Fri, 2014-02-21 at 16:47 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 04:19 PM, Simo Sorce wrote:
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.
On 02/21/2014 05:01 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 16:47 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 04:19 PM, Simo Sorce wrote:
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
On Fri, 2014-02-21 at 18:08 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 05:01 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 16:47 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 04:19 PM, Simo Sorce wrote:
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.
On Fri, 2014-02-21 at 19:04 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 06:33 PM, Simo Sorce wrote:
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.
Thanks you :-)
Simo.
On 02/21/2014 07:29 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 19:04 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 06:33 PM, Simo Sorce wrote:
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 :)
JBG
Am 21.02.2014 20:33, schrieb Jóhann B. Guðmundsson:
On 02/21/2014 07:29 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 19:04 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 06:33 PM, Simo Sorce wrote:
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 :)
please stop that thank you!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri 21 Feb 2014 02:33:57 PM EST, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 07:29 PM, Simo Sorce wrote:
On Fri, 2014-02-21 at 19:04 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 06:33 PM, Simo Sorce wrote:
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.
On Fri, 2014-02-21 at 15:00 +0000, "Jóhann B. Guðmundsson" wrote:
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.
On 02/21/2014 03:26 PM, Colin Walters wrote:
On Fri, 2014-02-21 at 15:00 +0000, "Jóhann B. Guðmundsson" wrote:
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
Hi Jóhann,
On Fri, 2014-02-21 at 15:25 +0000, "Jóhann B. Guðmundsson" wrote:
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
On 02/21/2014 03:34 PM, Colin Walters wrote:
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
On Fri, 2014-02-21 at 16:00 +0000, "Jóhann B. Guðmundsson" wrote:
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.
On Fri, Feb 21, 2014 at 11:09:47AM -0500, Colin Walters wrote:
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 :)
On Fri, 2014-02-21 at 16:00 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:34 PM, Colin Walters wrote:
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.
Am 21.02.2014 17:16, schrieb Simo Sorce:
On Fri, 2014-02-21 at 16:00 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:34 PM, Colin Walters wrote:
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
On Fri, 2014-02-21 at 17:36 +0100, Reindl Harald wrote:
Am 21.02.2014 17:16, schrieb Simo Sorce:
On Fri, 2014-02-21 at 16:00 +0000, "Jóhann B. Guðmundsson" wrote:
On 02/21/2014 03:34 PM, Colin Walters wrote:
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 :)
- 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
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.
server@lists.fedoraproject.org
-
Adam Williamson -
Anthony Joseph Messina -
Colin Walters -
David Timothy Strauss -
Jóhann B. Guðmundsson -
Matthew Miller -
Reindl Harald -
Simo Sorce -
Stephen Gallagher