Network configuration future

[Miloslav Trmač]

Hello,
On Wed, Aug 29, 2012 at 1:58 PM, Olaf Kirch <okir at suse.de> wrote:
> While I my original motivation in working on this is from a SUSE perspective,
> I believe other Linux distributions can benefit from this as well, and I'd
> be happy to work on this cross-distribution.
>
> Your feedback is very much welcome!

It would be great to have feedback from people actually currently
working in related areas; I can offer primarily the general
distribution perspective:

The move to NetworkManager took many years, still isn't complete
(NetworkManager still isn't a full-featured replacement of the Fedora
initscripts) and the impact on users has been rather painful:
* API users: Programs had to be modified to work with both systems
* Command-line interface and configuration files have changed (the
most common use cases were covered, but there are differences)
  * As a sub-case, once users are told they have to switch to the "old
system" to get their features working, they will be reluctant to try
the "new system" again soon.
* GUI has been broken by NM API changes at least once, and can not
rely on NM presence
* Documentation has had to cover both solutions.

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.



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-correctly-to-the-letter)
in documentation.

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