Rework NetworkUpdate workaround #950
Conversation
|
I've updated this to make use of the new NetworkUpdateCompat which takes care of this at the digitalocean/go-libvirt level. |
|
Thank you @cfergeau ! I hope it gets merged soonish |
|
@dmacvicar is this missing anything to get reviewed? |
…rtxml This is the same go module, it was renamed so that it can start following go module versioning (only change major version if there are API/ABI breakages). github.com/libvirt/libvirt-go-xml is no longer maintained/updated.
The libvirt version check which is currently to decide whether to swap libvirt.NetworkUpdate arguments is not enough. The fix was backported to older libvirt in RHEL/CentOS (for example in libvirt-6.0.0-37.1.module+el8.5.0+13858+39fdc467 ), and the current version checking code would be swapping the arguments when it's no longer needed. This commit uses NetworkUpdateCompat which was recently introduced in digitalocean/go-libvirt, and which takes care of this by checking libvirt connection features.
Done! I squashed the commit fixing linting in NB: since 'Allow edits by maintainers' is checked, you could add a |
The libvirt version check which is currently to decide whether to swap
libvirt.NetworkUpdate arguments is not enough. The fix was backported to
older libvirt in RHEL/CentOS (for example in
libvirt-6.0.0-37.1.module+el8.5.0+13858+39fdc467 ), and the current version
checking code would be swapping the arguments when it's no longer needed.
This commit uses the same code as libvirt client libraries instead, it
checks if the libvirt connection supports the new NetworkUpdate call or
not. I've tested this code with both libvirt-6.0.0-37.1 and
libvirt-6.0.0-37 and in each case, the correct call was done to
libvirt.NetworkUpdate
Please make sure you read the contributor documentation before opening a Pull Request.