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

[Cole Robinson]

On 10/05/2018 11:13 AM, 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).
> 

Thanks for the write up.

Do you know any application besides virt-manager that actually uses the 
interface APIs? Maybe we should start moving in the direction of killing 
netcf. I'd be happy to make that happen for fedora 30.

As for the interface APIs, I don't know if that means we ship no backend 
in Fedora, or use the udev backend. Maybe we just fold the udev backend 
impl into the nodedev XML so nodedev APIs also list logical interfaces 
like bridges. Yeah it will only show them when they are active, but 
since the APIs won't have any way to change interface state that seems 
okay to me.

- Cole