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

[Richard W.M. Jones]

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 ""?

> Then, any plugin that wants to advertise a different default export
> name supplies .default_export, and if .default_export is missing, we
> supply "" on their behalf.  We could also translate a client request
> for "" into .default_export before calling .open (v3) or populating
> nbdkit_export_name (v2) (I could see that mattering for the file
> plugin with a mode that serves all files in a directory, since
> stat("") fails but providing a default filename as the largest file
> in the directory could be useful).
> 
> >Then we could implement --run transparently by having it set
> >$exportname/$uri to the first entry in .list_exports or "" if
> >.list_exports is not implemented.
> >
> >Here's another idea: Is it possible that if the --run script itself
> >overrides exportname it could be used by $uri.  Not sure if there's
> >some kind of delayed shell variable expansion that would make this
> >possible:
> >
> >   nbdkit ... --run 'exportname=foo; nbdsh -u $uri ...'
> 
> Not as written, but we _can_ do the following.  Right now, --run
> creates a shell fragment, which prepends this code in front of the
> user's:
> 
> uri=...
> nbd=...
> ...
> exportname=...
> 
> 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.

> 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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org