[Libguestfs] [PATCH nbdkit] server: Deprecate the -e/--exportname parameter.

[Eric Blake]

On 7/22/20 6:25 AM, Richard W.M. Jones wrote:
> On Wed, Jul 22, 2020 at 06:12:30AM -0500, Eric Blake wrote:
>> On 7/22/20 4:02 AM, Richard W.M. Jones wrote:
>>> Perhaps we should have a rule something like this:
>>>
>>>   - plugins should serve default content on the "" export
>>>
>>>   - unless they implement .list_exports, in which case the
>>>     first export returned is the default export
>>
>> That could be expensive, reading the entire list and throwing away
>> all but the first. I'm now leaning towards two callbacks:
>>
>> .list_exports: compute all exports to advertise
>> .default_export: compute the name to be returned for
>> NBD_OPT_INFO("") and to use by default as $exportname in --run
> 
> Maybe I don't understand this, but isn't NBD_OPT_INFO("") explicitly
> asking for info about the "" export name?  In what situation would
> .default_export ever return anything other than ""?

The NBD protocol permits it in replies to NBD_OPT_INFO:

     * `NBD_INFO_NAME` (1)

       Represents the server's canonical name of the export. The name
       MAY differ from the name presented in the client's option
       request, and the information item MAY be omitted if the client
       option request already used the canonical name.  This
       information type represents the same name that would appear in
       the name portion of an `NBD_REP_SERVER` in response to
       `NBD_OPT_LIST`.

That is, when I added NBD_OPT_INFO to the NBD protocol, I specifically 
envisioned a server where if the client asks "I want the default export, 
what am I going to be served?" the server can then reply with a 
canonical name rather than "".

>> we could instead prepend:
>>
>> set_export() {
>>    uri=...
>>    nbd=...
>>    ...
>>    exportname=$1
>> }
>> set_export ...
>>
>> where that last line uses .default_export (defaulting to "" as
>> usual). The user can now run:
>>
>> nbdkit ... --run 'set_export foo; nbdsh -u "$uri" ... '
> 
> Cure is beginning to sound worse than the disease.  We can bring back
> -e but only for the narrow use case of specifying an export name for
> --run and with lots of documentation about why it's needed.

Yep, now you see why I was starting to complain that we were premature 
on crippling -e with --run.

> 
>> Oh, and I just realized, because $uri can contain ?, we really
>> should scrub all uses in the tree to always write it as "$uri"
>> rather than unquoted, just to set a good example.  (It's unlikely
>> that anyone would ever have a subdirectory named 'nbd+unix:' in
>> their current working directory to the point that the ? would
>> trigger unintended globbing, but better safe than sorry...)
> 
> Yes indeed.

As that's an easy scrub, I'll probably complete it momentarily.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org