[libvirt] [PATCH] virsh: let 'connect' without args remember -c option

[Eric Blake]

On 06/11/2012 09:33 AM, Eric Blake wrote:
> On 06/11/2012 07:01 AM, Daniel P. Berrange wrote:
> 
>> Personally I think we should return a fatal error if the user
>> attempts to use 'connect' in non-interactive mode, and not try
>> to hack it to behave the same as --connect/-c.
> 
> I still think that 'connect URI' is useful in non-interactive mode - I
> can see batching up a series of commands that crosses several
> connections, and therefore where using 'connect' in that batch to swap
> connections makes sense.
> 
> But I think I can agree to the idea that if we are non-interactive (ie.
> stdin is not a tty), then 'connect' without arguments always giving an
> error instead of (re-)trying a NULL connection or even remembering the
> -c option would make sense.  As for the particular issue I was trying to
> solve, having 'connect' without arguments error out would at least avoid
> my issue of 'make check' taking forever when it gets to the 'virsh
> connect' call.

I'm worried that making 'virsh -c $URI connect' fail would break
existing scripts that probe whether a connection is viable.  We don't
really have any other way to do a non-invasive probe of whether a
connection has sufficient access rights, although I suppose you can do
things like 'virsh -c $URI list' and ignore the output, for almost the
same effect.

Also, remember that commit d218344e changed things to avoid connecting
until we HAVE to use the connection, so things like 'virsh -c $URI echo'
are not a viable way to test for a valid connection, since 'echo'
doesn't need a connection to operate.  That is, 'virsh -c' is documented
as behaving like 'connect URI', except that the connection is only
attempted if the rest of the command line has to use the connection.

> 
> And I _still_ think that we need to fix 'connect URI' to not lose the
> current connection until after the new connection is established, as it
> is better than the current behavior that kills the current connection
> first even if the new connection is not possible.
> 
> I'll try to incorporate all of this into a v2.

Still not written, because I don't think we have settled on semantics.

What about this proposal:

Add a new option --default to 'virsh connect'.  An explicit 'connect
--default' (whether interactive or specified in batch mode on the
command line) allows you to connect to the NULL URI (and thus we have a
way to rely on libvirt.so's default connection rules without having to
type in our desired default connection), no matter what your current
connection state is.

Obviously, 'connect URI' means to attempt to URI, but we fix things so
that if the new connection fails, virsh remains in the same connection
state that it was previously (whether or not it has already connected to
a previous domain).

Finally, 'connect' without either URI or --default changes meaning to
force connection to the current URI, rather than the old semantics of
opening a new connection to the NULL URI.  Thus, 'virsh -c
test:///default connect' would now mean that we ensure that we are
connected to test:///default; 'virsh connect' is shorthand for 'virsh
connect --default'; 'virsh "connect $URI; list; connect --default;
list"' lets us toggle between two connections in one batch command, and
'virsh "connect $URI; list; connect"' treats the second connect as a
no-op because we are already in a connected state with $URI and
--default was not given.

Scripts that use connect to probe for valid ability to connect will
still continue to work.  And the new option --default means that users
can still trigger a connection to a NULL URI, but the extra verbosity
means that 'connect' in isolation will no longer be quite so surprising.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120611/9b676fbd/attachment-0001.sig>