Network configuration future

[Dan Williams]

On Mon, 2012-09-03 at 09:44 +0200, Olaf Kirch wrote:
> 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.

NM tries to hide things where it makes sense; there's a *lot* of stuff
that is simply unnecessary for clients to care about while handling
networking.  But there's a lot of stuff administrators and clients also
want to change, and we're moving pretty quickly in that direction
already.  There are a lot more knobs in NM than people realize.

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

And that pretty much describes how NM works today too; it'll handle your
existing network configuration, but still does expose a lot of tunables
in the configuration.

But you have to ask whether those knobs are actually required.  Knobs
fall into one of three classes:

1) useful ones, like IPv6 privacy settings, IPv6 on/off, etc
2) dubious ones, where the kernel or low-level implementation just tries
to avoid hard choices and decides to give up 
3) workarounds for broken hardware or kernel drivers

We've tried really hard over the past 6 or so years to *not* expose
knobs that allow people to work around broken kernel stuff or hardware,
and instead *fix* the kernel to do the right thing instead of expecting
users to know which knob to twiddle to get the right result.  Examples
of this include SSID scanning in wifi drivers and carrier detection
capability in wired drivers.

Nobody should ever have to know whether their driver supports a specific
feature or not and then set some option because of that; instead we need
to fix this sort of thing in the kernel and then handle it
automatically.

My point is, not all knobs are worth exposing, and some knobs shouldn't
be exposed, but should get fixed so they don't need to be exposed in the
first place.  It's hard, but it makes life better.

Next, you need to analyze *why* a particular knob is requested.  Is
there a better way to do that?  I've often found people want a checkbox
for this or that, when there's actually a much better way to fix the
problem for the user.  Sometimes there's not and you just add the knob.
But often there is.  Adding knobs left and right often (a) increases
complexity and therefore confusion, and (b) creates code that's really
hard to maintain and document.

> > 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
> > HOPELESSLY_UNINTUITIVE_OPTION_NAME (or even
> > 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.

It actually works pretty well for most things, we've found.  We have
gone through rounds of trying to figure out better formats, but it turns
out that for the most part, the ifcfg format is:

1) widely used and thus well-understood
2) compatible with a huge number of existing tools
3) easily machine-parsible (except for embedding shell inside the
variables, ie backticks or whatever)
4) simple and fairly flexible

If you treat the file as a simple key/value file, and disallow using
actual shell macros or expansion, then it's actually pretty suitable.
And nothing else anyone has come up with is actually so much better that
it's worth the cost to switch.  I came up with the NetworkManager
"keyfile" format, and it's not hugely better, just cross-platform.  But
ifcfg will live a long, long time.

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

Yup, all the nice enterprise/virtualization stuff is actually extremely
complicated, and I think we can do better than the hodgepodge of scripts
that people currently use to handle things.

But in the end, it doesn't really help anyone to have competing network
management systems, lease of all users.  I haven't seen a great case for
one in preference to the other, or a great case against modifying one to
pick up the advantages one has over the other.

Dan

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