Network configuration future

Olaf Kirch okir at
Mon Sep 3 07:44:07 UTC 2012

Hi Miloslav,

On Wednesday 29 August 2012 18:42:44 Miloslav Trmač wrote:
> Considering that it's not reasonable to expect that the replacement
> will cover 100% of the previous functionality, the "old" and "new"
> projects will have to live side by side again for some time.  So a
> switch to a different system needs to provide benefits that exceed the
> quite large costs of the migration.
> Therefore, in general, I'd assume that modifying NetworkManager (in a
> backward-compatible way) is probably an easier way to add features
> than replacing the whole subsystem with something else.

Hm, I beg to differ here. NetworkManager aims at a relatively compact
DBus API that hides most of the complexities of the network stack.
That, I believe, is one of the major reasons why it hasn't caught on
much in an Enterprise world - there's always one little extra knob an
admin wants to twiddle.

By contrast, I think a good network management framework needs to
have a low entry barrier (in terms of writing configuration files)
but still expose as many of the tunables and knobs as possible.

> Now, with my once-upon-a-time sysadmin and initscripts comaintainer hat on:
> Yes, it is possible to design a better configuration format than the
> ifcfg files, but I'm not sure that this is a really pressing problem:
> the primary problem with networking is understanding the concepts and
> designing the desired state, not the configuration format - once you
> know what you want to do, you can always find the
> nicely-scoped/well-designed-option-name-that-you-need-to-write-precisely-co
> rrectly-to-the-letter) in documentation.

Sure, I'm not talking about the syntax. As I said, I couldn't care
less if its XML or anything else. My point was that the shell variable
syntax is unable to express anything but the most basic concepts,
and hence our network management remains simplistic.

> In addition to a different configuration format, having new features
> could be more attractive (e.g. the ability to replace a bonding slave
> without restarting the whole interface, or 802.1x support) - but
> because any of the implementations already cover the basic
> functionality reasonably well, the new attractive features would
> necessarily be something of a niche / not-that-frequently-used
> features.  So, again, it seems reasonable to assume that the new
> features might not be attractive enough to trump the costs of the
> migration.

Well, if you take each of these niche things by themselves, they
don't count for much. But they add up, and Cloud/Virtualization is
really adding a *lot* of complexity. netcf being a fine example of
the hoops you need to jump through in order to support the brave new
world of virtualization hosts.

My point is that the current system has reach a breaking point. We've
piled brick on brick, and the stack is teetering dangerously :)

And regarding your comment as to adding new features - that is
definitely in scope for wicked. It does already allow to change
the set of bonding slaves on the fly, and 802.1x support is on the
TODO list.

Neo didn't bring down the Matrix. SOA did. (
Olaf Kirch - Director SUSE Linux Enterprise; R&D (okir at
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) 

More information about the devel mailing list