starting Fedora Server SIG

[Jeremy Katz]

On Fri, 2008-11-14 at 13:13 -0500, Martin Langhoff wrote:
> On Fri, Nov 14, 2008 at 11:08 AM, Jeremy Katz <katzj at redhat.com> wrote:
> > One of the things about progress and getting to a more mature *platform*
> > that is suitable across a wide range of uses is change.  I'm not saying
> > that NetworkManager is perfect yet for the server needs.  But having
> > people that want to run a server say "pound sand, go the hell away, we
> > don't want to run your new-fangled stuff" doesn't help us get to where
> > it is.  Maintaining two systems in parallel is very much a long-run
> > losing position.
> 
> I agree with the desire to maintain only one tool. However, NM is
> extremely desktop oriented, and there seems to include no hint of an
> intention to support the complex setups that are possible with the old
> ifcfg infra.

Really?  Most of the work over the past couple of years in NM seems to
be aimed at trying to support these cases as opposed to just the
"simple" desktop case

> Scripting is actually a great fit for network config policies. All the
> NM goodies could be built into a much _much_ leaner program that can
> orchestrate different network configurations dynamically (ifcfg
> style). Right now it's a monolith -- I'm not tracking it closely, but
> nm-tool is slowly getting some very basic functions, and there's no
> scripting supported AFAICS.

The NetworkManager dispatcher stuff has existed forever and is all about
scripting.  Not necessarily pre-interface bringup, but post.  And
depending on scripting slows things down and makes it a lot harder to
have a deterministic view of what's been done.

And rather than focusing on nm-tool and exactly what it exposes, it's
probably more interesting to look at the dbus interfaces/daemon
capabilities.  Yes, I'll be one of the first to say it's painful to
write code interacting with dbus :-) -- but, it is very flexible and
then as what the real use cases that people care about become clearer,
it's easier to write very lean, very specific tools to do what they need
as long as the backend and dbus interfaces are sufficient

Jeremy