Re: [Qemu-devel] [Nbd] [PATCH] Further tidy-up on block status

[Wouter Verhelst]

On Wed, Dec 14, 2016 at 07:01:15PM +0000, Alex Bligh wrote:
> Wouter,
> 
> (Our mails crossed and I've actually pushed something, but no matter)
> 
> > On 14 Dec 2016, at 18:49, Wouter Verhelst <address@hidden> wrote:
> > 
> > What I was trying to say is that I think the result to _LIST_ with no
> > queries should return all information the client needs to theoretically
> > build the list of all possible contexts, even if that list may be
> > so large as to be unfeasible for it to be built (e.g., in case of a
> > cartesian product between all possible other contexts). I gave one
> > example, but there may be more.
> > 
> > My point is that if the query includes a namespace, the result should
> > not be defined by our spec. If the query does not include a namespace,
> > the result should be "complete" by whatever definition, but not
> > unreasonable (i.e., don't just write a cartesian product to a client).
> > 
> > This could allow an interactive client to present a user with a list of
> > possible contexts before performing analysis on the block device, say.
> 
> OK, so first of all, one of the changes I made earlier was that now
> each of the commands carries a list of queries, the way you list
> everything is not 'having a query that doesn't contain a namespace'
> but rather doing a _LIST_ with no queries at all. But that's semantics
> and orthogonal to the main point.
> 
> What I've proposed (and pushed - but feel free to alter it) is that
> 
> 1. on _LIST_, the server can return fewer contexts than are available
>    if returning all of them would consume undue levels of resources.
> 
> 2. on _LIST_ where the contexts are 'algorithmic', the server can
>    return e.g. 'X-Backup:' rather than 'X-Backup:modified>' and
>    every integer.
> 
> 3. On _SET_ if too many contexts are requested, the server may return
>    an error (I think we need this anyway).
> 
> That nearly does what you ask for, but I'm not sure how you any query
> could 'return all the information the client needs to build
> the list of all possible contexts'. For instance, in my backup
> example 'X-Backup:modified>[integer]' doesn't itself tell you
> anything, as you don't know whether the integer is a unix
> date time, in seconds after the epoch, milliseconds or whatever.
> What, surely, as a client you want to know is 'does it support
> the X-Backup: extension because I've read the spec for that and
> know that it has X-Backup:modified if so'. So I've suggested it
> return 'X-Backup:' only in that case, in which case from that
> (*and the spec*) you know how to build any query.

Actually, it does do what I ask for :-)

A client which knows about spec X, Y, or Z, should get all the
information from a _LIST_ command that it needs in order to know whether
or not it can request a particular context or not. E.g., in the case of
a "modified more recent than X seconds ago", the _LIST_ command should
expose (somehow, defined by the spec of that context) that it supports
that particular syntax, without requiring a list of all possible
integers between 0 and 2^64 (for obvious reasons).

This does require that the client know about a particular spec before it
can query it, but that's going to be the case anyway -- a client should
have no business asking for a context of which it has no implementation,
since that would mean it is asking the server to send it information
that it is then going to throw away anyway, which makes no sense.

Additionally, this also allows a client which sees that no contexts were
returned for one of the queries in its _SET_ command to differentiate
beween "server does not support metadata context XYZ" and "server does
support metadata context XYZ, but there is no relevant metadata context
for the query I sent". Allowing a server to limit the information it
sends at an arbitrary cut-off point of "20" or whatever would *not* do
that, so I'm against it in the strongest of terms.

Put otherwise: the information sent in return of a _LIST_ command with
no query string (i.e., the command that asks for "everything") should be
"complete" in the sense that it should allow a client to know whether a
server has support for metadata context X, Y, or Z, even if that means
it may have to issue further _LIST_ queries later on, or if it may have
to combine some other information first.

In the absense of dynamic namespaces, that is most easily implemented by
just listing all metadata contexts in all namespaces that we know about,
but it doesn't *have* to be that.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12