Laine's attempt long ago [1] to deprecate/obsolete the virInterface* APIs did
not receive a standing ovation. However he raised many good points which are
still valid today. If anything, netcf, the libvirt netcf backend, and the whole
interface driver have become more stale. Personally, I wish we could deprecate
and eventually obsolete the APIs and nuke the entire driver, but understand
that's not desirable/realistic upstream. Given the state of the thing, I'd like
to hear opinions on adding some words to the interface API page and
virtinterfaced man page that describe the state of the APIs/driver and
discourages their use.
The motivation for this request comes from my efforts to take advantage of
libvirt's modularization and not provide virtinterfaced
(libvirt-daemon-driver-interface package) for certain use-cases. Having upstream
documentation warning of the limitations and inactive development of the
APIs/driver would help in convincing unsuspected users to find a better
solution. And I think the use of "unsuspected" is correct :-). Projects closer
to libvirt, like virt-manager, ditched use of the APIs long ago. But projects
with less cross-pollination may not be aware of the general uselessness.
As an example, we recently discovered cockpit-machines uses
virConnectListAllInterfaces and virInterfaceGetXMLDesc. It's not clear to me why
cockpit gathers this info. AFAICT it's not used for anything. The code was added
long ago [2] with no info on purpose or what it's supposed to achieve. We've
opened a github issue [3] to discuss removing use of these APIs. Pointing
cockpit-machines developers to upstream libvirt documentation that describes the
state of virInterface* and sets realistic expectation might help in convincing
them to follow virt-managers footsteps and drop use of the APIs.
I can provide the words of discouragement in the form of a patch if folks are
receptive to the idea :-).
Regards,
Jim
[1] https://listman.redhat.com/archives/libvir-list/2020-December/212791.html
[2] https://github.com/cockpit-project/cockpit/pull/12465
[3] https://github.com/cockpit-project/cockpit-machines/issues/1777
