On Mon, 2020-07-20 at 18:21 +0100, Daniel P. Berrangé wrote:
On Mon, Jul 20, 2020 at 07:18:55PM +0200, Andrea Bolognani wrote:
The other day I randomly realized the ssh-based transports already accept a 'netcat' URI parameter which can be used to point libvirt to a non-standard nc stand-in. With that in mind, is it really necessary to introduce another URI parameter? Can't we just reuse the existing one?
Any binary provided there needs to implement netcat syntax. The whole point of this work is that we don't want to use the netcat syntax since it is impossible to know the correct socket path.
We could special-case binaries called 'virt-nc' and use our internal syntax for those. Having two separate URI parameters to control the same knob sounds like trouble, especially since you can mix and match: if you try to connect to qemu+ssh://host/system?proxy=virt-nc&netcat=my-cool-nc for example, what happens? As far as I can tell virt-nc will be used, but it's certainly not as obvious as it would be if everything was controlled by a single URI parameter. Actually, and I might be very well missing something because I looked at the code rather quickly, from what I can tell the default value for proxy will cause libvirt to always prefer virt-nc when available, which means that the URI qemu+ssh://host/system?netcat=my-cool-nc will suddenly stop using my-cool-nc and start using virt-nc after libvirt has been upgraded - a breaking change. -- Andrea Bolognani / Red Hat / Virtualization