On Wed, Dec 02, 2020 at 02:47:53PM -0500, Laine Stump wrote:
1) Does this generally sound like a good direction? Or is there
something
I'm ignoring that renders my points moot?
2) If we are going to do it, how should we proceed?
We obviously can't simply *remove* the virInterface API from libvirt (since
that would destroy backward compatibility guarantees), but could immediately
begin logging some sort of "this API is deprecated" message when any of the
functions are called, and then in a later release change the APIs to return
an error (while simultaneously removing netcf from the build and dependency
lists). At the same time, we would need to decide if the "interface status"
functionality needs to be maintained within appropriate virInterface*()
APIs, reproduced in virNodeDeviceGetXMLDesc(), or just dropped altogether.
We should *NOT* deprecate the public APIs. The design of them is perfectly
valid and can accept any other implementation in future.
A more viable impl of network APIs could be to back them by Networkmanager,
or systemd network, or whatever is relevant to a particular platform
If we want to drop netcf because the project is unmaintained that is fine,
the APIs simply return an VIR_ERR_NO_SUPPORT code as with any other API
that has no impl in a particular hypervisor.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|