Network configuration future

[Dan Williams]

On Thu, 2012-08-30 at 07:44 +0200, Olaf Kirch wrote:
> Hi Adam,
> 
> On Thursday 30 August 2012 04:16:23 Adam Williamson wrote:
> > > *** Network Manager is just another daemon created for a task
> > > which historically often did not need any daemons. It's almost as if
> > > the new generation of Unix hackers wants to redo everything -
> > > in x10 or x100 times bloated and more complex way than it was done
> > > before.
> > 
> > <snip>
> > -
> > > One, a modern network management framework should run as a service.
> > > The
> > > kernel offers a plethora of notifications via rtnetlink, and
> > > increasingly
> > > expects user space to react to these (for instance in the IPv6 area).
> > > Running a network management daemon allows us to track the state,
> > > detect
> > > changes, and react to them appropriately.
> > 
> > There appears to be some cognitive dissonance in the document. It seems
> > odd to criticize NetworkManager solely for being a bloated, complex
> > daemon, and then, having dismissed NM, in describing the ideal
> > next-generation network management framework, declare that it ought to
> > be a bloated complex daemon...
> 
> That dissonance is explained easily. Only the second section you quote was
> written by me, the other is a comment from Denis Vlasenko, actually :-)
> 
> And no, I'm not criticizing NetworkManager for being bloated. My main
> criticism of NetworkManager is that it's very much focused on managing
> desktop machines, and it's not flexible and extensible enough to make it
> handle server scenarios, much less vhost setups. It is also hard to make it
> coexist peacefully with other network management on the system - if you
> start NetworkManager, it tends to take possession of all interfaces
> it finds (and understands).

That's NM's heritage, but that's certainly not its focus.  We're
actually focusing a *lot* more on enterprise use-cases these days,
including lots of knobs that admins like to turn.

The main coexistence problems center around two things: DNS and the
default route.  In *any* system you need one thing to manage these,
because they are a shared resource.  Which interface gets default route
priority?  Which interface's DNS servers get priority?  If the thing
that manages these doesn't have the full information available to it,
like the user preferences for these options, then you'll end up not
making the right choices.  The thing that manages these must have
information about *all* interfaces.

*That's* the problem with multiple competing network management systems.
If it weren't for this, they'd all be just fine managing the individual
interfaces they were told to manage.  But unfortunately the default
route and DNS are somewhat crucial to networking...

NM has historically attempted to manage both of these, because it had a
lot of information.  And that creates some problems.  We're working on
ways to mitigate this issue, but it's not a problem that's easily solved
when some people like to use one system, and other people like to use
another system.  And adding another layer of abstraction to the system
to mitigate between network management systems doesn't help a lot
either.... :(

Dan

> And no, I'm not advocating a bloated daemon either. Network management
> has to fit into initrd and possibly small-footprint images. Currently,
> wickedd, its library and the dhcp4/dhcp6 helpers fit into a little over
> 1 MB.
> 
> By contrast, the ISC dhlient comes in at 1.6MB on my system already.
> 
> Regards,
> 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)