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