Re: [Qemu-devel] [PATCH v2 3/6] qapi: add nbd-server-remove

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3757 bytes --]

On 01/17/2018 07:36 AM, Vladimir Sementsov-Ogievskiy wrote:

>>>> looks interesting. what about the following naming?
>>>>
>>>> @mode: possible values:
>>>>                hide - just hide server from new clients, maintain
>>>> existing connections,
>>>>                            remove after all clients disconnected
>>>>                soft - like hide, but answer with ESHUTDOWN for all
>>>> further requests from
>>>>                            existing connections
>>>>                hard - hard disconnect all clients and remove server
>>>>                (default: soft)
>>> Or even a fourth mode that causes an immediate error return without
>>> state change if there are any connected clients, but otherwise removes
>>> the server.
>>>
>>>> new corresponding states of nbd export:
>>>> hidden, shutting_down
>>>>
>>>> and we allow transitions:
>>>>
>>>> normal_execution -> hidden
>>>> normal_execution -> shutting_down
>>>> normal_execution -> exit
>>>> hidden -> shutting_down
>>>> hidden -> exit
>>>> shutting_down -> exit
>>> Seems reasonable.  Are you planning on tackling a respin of this series
>>> incorporating that idea?
>>>
>>
>> yes, will do.
>>
>>
> 
> Discussed with Nikolay.
> For now we actually need only one mode: hard.
> In near future we _may be_ will need your proposed fourth mode (what
> about "safe" name for it ?)

'safe' sounds reasonable.

Of course, if we only have two modes at front ('safe' which returns an
error if a client is connected, and 'hard' which disconnects all clients
immediately; leaving 'hide' and 'soft' for the future), then we don't
have to worry about a state transition or any hidden exports.

A QAPI enum with only two values now is at least extensible in the
future if someone has a need for another mode, and introspectible to
learn which modes are currently supported.

> 
> I was going to implement all 4 modes, but now I doubt, isn't it too
> hastily, to introduce 3 new modes to the
> interface, which we (personally) do not need. May be it is better to
> start from one or two modes.

Starting with just two modes is fine as well.

> 
> Finally what do you think, Eric? Which modes do you need?

'hide' may be interesting for the purpose of connecting a single client,
then hiding the export so no other clients can connect, while waiting
for the first client to take its time.  But right now, I don't have
actual use cases in mind so much as making sure we aren't limiting
ourself from future expansion as needs are identified, so a conservative
choice of just 'safe' and 'hard' for now is reasonable.

> 
> ps: I've created hmp version for 2/6, it will be in v2.
>  also, I'm going to add query-nbd-server, which should list all exports

Sounds good.

> 
> also, about HMP: If I understand correctly, people use it because
> writing qmp command by hand is not very comfortable.
> I have a script (for managing libvirt guest, but it can be adopted for
> qemu or even used for qemu monitor), which allows
> me run qmp commands on vms as easy as:
> 
> |qmp VMNAME query-block-jobs or qmp VMNAME nbd-server-remove name exp1
> mode hard or even |
> 
> |qmp VMNAME blockdev-add id disk driver qcow2 cache {writeback true
> direct true} aio native discard unmap file {driver file filename
> /tmp/somedisk} |||

Yeah, there are various scripting solutions around QMP that can make it
easier; but HMP is often still an easy front-line interface for experiments.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]