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

[Pavel Hrdina]

On Fri, Oct 05, 2018 at 11:13:15AM -0400, Laine Stump wrote:
> 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).

That was verbose answer :) anyway, nice summary of what was happening.

I can only agree with Laine that we can safely remove this UI from
virt-manager.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20181007/31089f1f/attachment.sig>