On 08/20/13 22:40, Eric Blake wrote:
On 08/20/2013 02:30 PM, Eric Blake wrote:
> I'm not a fan of this. We worked hard to get some commands (like 'virsh
> echo') to NOT need a connection, and this would be undoing that work. I
> think we should NOT autoconnect UNTIL we reach the point that completion
> is being attempted on something where a connection is needed to get the
> completer list, rather than this code which autoconnects regardless of
> whether we need completion. Having 'virsh echo' avoid an autoconnect is
> useful - it can be used to prove whether virsh itself is working or has
> a problem such as a missing .so, without complicating the diagnosis with
> a question of whether it is a bad default connection to blame.
More along that line of thought:
If I type:
$ virsh
virsh> e<TAB>
I want a completion to list all commands that start with 'e'; one of
those commands is 'echo', which does not need a connection.
Therefore, if I use the shell:
$ virsh e<TAB>
and the shell uses, under the hood,
$ virsh complete e
that particular completion attempt should NOT attempt an autoconnect,
because it is not completing on any information that requires a
connection. autoconnect to qemu:///session can be noticeably
time-consuming on the first time it is attempted. Although the session
server tends to stick around for a few seconds after the last
connection, so that future connection attempts in a short timeframe are
serviced faster, you still don't want to pay the penalty for a delay for
the first autoconnect until it is mandatory for the completion at hand.
Whereas an interactive virsh keeps one connection open across multiple
uses, the bash completion routines will be invoking a different instance
of 'virsh' for every <TAB> hit on the shell command line, where we want
each instance to be as fast as possible.
Also if a user decides to use a ssh-tunneled connection as default but
will not use ssh keys for authentication each completion attempt will
request the password from the user, which might get annoying.
Peter