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 :|