Re: [libvirt PATCH 9/9] rpc: use new virt-nc binary for remote tunnelling
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