[virt-tools-list] RFC: virt-manager: removing interface object UI

[Laine Stump]

On 10/03/2018 04:23 PM, Cole Robinson wrote:
> Hi all,
>
> I'd like to remove the <interface> object UI from virt-manager. This
> is Edit->Connection Details->Interfaces, the bits that allow
> starting/stopping/deleting/creating host network interface
> configurations like bridges, bonds, vlans, and ethernet/wifi configs
>
> https://imgur.com/a/iyYXawV
> https://imgur.com/a/lGO4QZ0
>
> Long story short 1) I don't think this UI makes sense to have in
> virt-manager, 2) no one seems to be using it.
>
> Most of this UI was added about 8.5 years ago to virt-manager. It has
> mostly been unchanged since. At the time it seemed kind of compelling
> that we could use the UI to create a host bridge device. However this
> never quite 'just worked' often due to interference with
> NetworkManager which really only learned to handle bridges in 2014ish
> (even now I don't think it 'just works'). Since that time
> nm-connection-editor provides a much more advanced UI for configuring
> host network interfaces of all types.
>
> virt-manager's UI supports a lot more than just creating bridges
> though, basically covering the entire <interface> schema in libvirt:
> so configuring ipv4 and ipv6, various bond modes, etc. However no one
> uses it. I'd bet good money that there's been 0 non-virt-developer
> users of the 'Create Interface' wizard for something other than bridge
> creation.

Actually the largest use I've seen of virt-manager's Interface API
support is from people who misunderstand that it is for managing *host*
interfaces, and instead believe that they need to create one of these
interfaces for each guest, and then when they can't, they mistakenly
believe that guest networking is broken (this happened on IRC just a
week or two ago). It is made worse by:

1) some distros using the udev backend for the interface API, which only
supports reporting *currently active* devices (not device configurations)

2) Arch Linux apparently has a "port" of the netcf package (the other
backend for the interface API) which was made by simply getting the
Fedora version of the code to *compile* - it doesn't actually do
anything useful.

In case (1), all the APIs (including those to
define/undefine/start/destroy interfaces) are present, but
create/delete/start/destroy fail; only list and dumpxml work. In case
(2) all of the APIs are still there but they *all* fail. This leads to
even more confusion and frustration.

> The UI for starting/stopping interfaces may have had more usage but
> I'm fine telling people to go to the command line if they need to
> change host interface state. These types of things are not virt
> specific in any way and have little to specifically do with virt,
> besides bridges.
>
> Also as a side point, I don't think any major libvirt users are
> actually using the libvirt interface APIs aside from maybe listing
> existing interfaces. I thought vdsm/rhev/ovirt had some interface
> usage at one point but I looked recently and don't see any...

Right. The original intent as I understand it (I came in partway through
the initial discussion/design, wrote the libvirt APIs hooking up to
netcf, and took over maintainership of netcf after the original author
moved on), was that someone thought that a management system like ovirt
needed the ability to provision a virtualization compute node completely
from a single API, and one of the things they needed was the ability to
attach the physical ethernet to a bridge, *and* they wanted libvirt
provide that one API. In the end though, they wanted other things not
available from libvirt's interface API (and which went beyond the scope
of libvirt's API, so they did their own thing and ended up not using
libvirt for that task anyway. Since then it has been more of a
curiousity, and a source of bug reports, than anything else (well, there
was awhile when the "virsh iface-bridge eth0 br0" command worked very
nicely, but behavior changed with each new release of NetworkManager)

>
> virt-manager will still use interface APIs behind the scenes, to get
> lists of host interfaces for enumerating bridges for example, but
> that's really all I see for virt-manager going forward
>
> Comments?


Where to begin? Oh, I guess I already have :-)

(The following is my opinion; others may disagree, and I'm always open
to hearing a less cynical view than my own :-))

We didn't realize it back in 2008-2009, but netcf (the backend of
libvirt's interface API) was doomed from the start (again, in my
opinion) for several reasons:

1) In order to really catch on, netcf (and thus libvirt's virInterface
APIs) would need to work well on at least *most* distros (and for all
supported versions of any supported distro), and the behavior would need
to remain consistent from version to version. But (unlike most other
functionality in libvirt, where at least the code is identical for
different Linux distros, with maybe a few small differences here and
there) there are too many different models of host network configuration
(different distros, different releases of those distros, multiple
solutions on a single distro) that would need to be catered to in order
to make the concept of a single unified network configuration API work
on all those distros/versions/network config subsystems, and since since
each camp already has a working API available, it's difficult to
convince anyone of the usefulness of putting in a bunch of work just to
create a different API that does the same thing (from their POV) as the
existing API

A few anecdotes about "support" for various distros: danpb went to the
effort to create a debian port of netcf to hopefully jumpstart support
on other distros, but it never really got much love from debian/ubuntu
people; there was a Suse port written and abandoned by someone whose
company used Suse in some embedded product (he stopped working on it due
to employer restrictions iirc), but afaik the suse folks themselves had
their own ideas about network configuration and weren't interested in
enhancing/maintaining anything in netcf; then someone from gentoo (iirc)
made a backend for the libvirt interface API that used udev to report
the currently active interfaces on the host (*not* their configuration)
and it didn't/doesn't support any of the APIs to manage configuration or
lifecycle of the interfaces - this was both a blessing and a curse. And
as for ArchLinux - someone modified the netcf source just enough to make
it *build* on Arch, and added it to their package repo (or whatever it
is they have), but it made no effort to actually read/write Arch's
config files, so it was in all respects a curse.

2) In many cases there is more than one way to represent one particular
config on a host (making netcf's operations on the config non-idempotent
at the least, and unable to cope with strange methods of configuring at
worst (e.g. on debian/ubuntu the network config can be in multiple
files, and I think it can include raw shell commands, but netcf will
always write it to a single file), The fact that the method used for
reading/writing config files (augeas) ignores/discards anything
unrecognized (unsupported options, comments) certainly doesn't help
anything.

3) The rest of the network eco-system is constantly changing in subtle
ways that make it nearly impossible to continue operating properly
without constant tweaks. One example - on systems that use ifcfg files
(Fedora/RHEL/CentOS), in the past it was necessary to separately ifup a
bridge device and the ethernet that was attached to it (and during
certain periods/conditions it was necessary to ifup the bridge first and
then the ethernet, and at other times/conditions the order had to be the
opposite. But recently I've noticed that an ifup of the bridge will take
care of both. Oh, but this changes if NM is disabled (or it did a year
or two ago -  Seriously I gave up trying to keep track awhile back.)


4) internally - augeas is cool (the library used to read/write the
config files) and all, but it's a bit strange and, I don't know about
anyone else, but netcf is the *only* place I ever use xslt (netcf uses
it to translate an augeas config tree to/from xml). Unfortunately,
unfamiliarity and busy schedules combine to produce neglect.


I know this is more of an answer than you were looking for, but to
shorten it - I personally have no problem with you removing the libvirt
Interface API UI from virt-manager, and I see this as another symptom
that the virInterface API is mostly unnecessary, unused, and maybe
should be included in current discussions about deprecating features in
libvirt (perhaps with the exception of the ListAllInterfaces API).