From: Lukas Straub <lukasstraub2@web.de>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-block <qemu-block@nongnu.org>,
"Juan Quintela" <quintela@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Max Reitz" <mreitz@redhat.com>
Subject: Re: [PATCH v7 1/8] Introduce yank feature
Date: Fri, 4 Sep 2020 14:33:05 +0200 [thread overview]
Message-ID: <20200904141312.185a20d5@luklap> (raw)
In-Reply-To: <871rjs9ser.fsf@dusky.pond.sub.org>
[-- Attachment #1: Type: text/plain, Size: 3990 bytes --]
On Thu, 27 Aug 2020 14:37:00 +0200
Markus Armbruster <armbru@redhat.com> wrote:
> I apologize for not reviewing this much earlier.
>
> Lukas Straub <lukasstraub2@web.de> writes:
>
> > The yank feature allows to recover from hanging qemu by "yanking"
> > at various parts. Other qemu systems can register themselves and
> > multiple yank functions. Then all yank functions for selected
> > instances can be called by the 'yank' out-of-band qmp command.
> > Available instances can be queried by a 'query-yank' oob command.
> >
> > Signed-off-by: Lukas Straub <lukasstraub2@web.de>
> > Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> ...
> > diff --git a/qapi/misc.json b/qapi/misc.json
> > index 9d32820dc1..0d6a8f20b7 100644
> > --- a/qapi/misc.json
> > +++ b/qapi/misc.json
> > @@ -1615,3 +1615,48 @@
> > ##
> > { 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
> >
> > +##
> > +# @YankInstances:
> > +#
> > +# @instances: List of yank instances.
> > +#
> > +# Yank instances are named after the following schema:
> > +# "blockdev:<node-name>", "chardev:<chardev-name>" and "migration"
> > +#
> > +# Since: 5.1
> > +##
> > +{ 'struct': 'YankInstances', 'data': {'instances': ['str'] } }
>
> I'm afraid this is a problematic QMP interface.
>
> By making YankInstances a struct, you keep the door open to adding more
> members, which is good.
>
> But by making its 'instances' member a ['str'], you close the door to
> using anything but a single string for the individual instances. Not so
> good.
>
> The single string encodes information which QMP client will need to
> parse from the string. We frown on that in QMP. Use QAPI complex types
> capabilities for structured data.
>
> Could you use something like this instead?
>
> { 'enum': 'YankInstanceType',
> 'data': { 'block-node', 'chardev', 'migration' } }
>
> { 'struct': 'YankInstanceBlockNode',
> 'data': { 'node-name': 'str' } }
>
> { 'struct': 'YankInstanceChardev',
> 'data' { 'label': 'str' } }
>
> { 'union': 'YankInstance',
> 'base': { 'type': 'YankInstanceType' },
> 'discriminator': 'type',
> 'data': {
> 'block-node': 'YankInstanceBlockNode',
> 'chardev': 'YankInstanceChardev' } }
>
> { 'command': 'yank',
> 'data': { 'instances': ['YankInstance'] },
> 'allow-oob': true }
This proposal looks good to me. Does everyone agree?
Regards,
Lukas Straub
> If you're confident nothing will ever be added to YankInstanceBlockNode
> and YankInstanceChardev, you could use str instead.
>
> > +
> > +##
> > +# @yank:
> > +#
> > +# Recover from hanging qemu by yanking the specified instances.
>
> What's an "instance", and what does it mean to "yank" it?
>
> The documentation of YankInstances above gives a clue on what an
> "instance" is: presumably a block node, a character device or the
> migration job.
>
> I guess a YankInstance is whatever the code chooses to make one, and the
> current code makes these three kinds.
>
> Does it make every block node a YankInstance? If not, which ones?
>
> Does it make every character device a YankInstance? If not, which ones?
>
> Does it make migration always a YankInstance? If not, when?
>
> > +#
> > +# Takes @YankInstances as argument.
> > +#
> > +# Returns: nothing.
> > +#
> > +# Example:
> > +#
> > +# -> { "execute": "yank", "arguments": { "instances": ["blockdev:nbd0"] } }
> > +# <- { "return": {} }
> > +#
> > +# Since: 5.1
> > +##
> > +{ 'command': 'yank', 'data': 'YankInstances', 'allow-oob': true }
> > +
> > +##
> > +# @query-yank:
> > +#
> > +# Query yank instances.
> > +#
> > +# Returns: @YankInstances
> > +#
> > +# Example:
> > +#
> > +# -> { "execute": "query-yank" }
> > +# <- { "return": { "instances": ["blockdev:nbd0"] } }
> > +#
> > +# Since: 5.1
> > +##
> > +{ 'command': 'query-yank', 'returns': 'YankInstances', 'allow-oob': true }
> ...
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-09-04 12:37 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-04 8:11 [PATCH v7 0/8] Introduce 'yank' oob qmp command to recover from hanging qemu Lukas Straub
2020-08-04 8:11 ` [PATCH v7 1/8] Introduce yank feature Lukas Straub
2020-08-27 10:31 ` Daniel P. Berrangé
2020-08-27 12:37 ` Markus Armbruster
2020-08-27 14:28 ` Daniel P. Berrangé
2020-08-28 14:21 ` Lukas Straub
2020-08-31 7:47 ` Markus Armbruster
2020-09-04 12:33 ` Lukas Straub [this message]
2020-09-04 12:47 ` Eric Blake
2020-08-04 8:11 ` [PATCH v7 2/8] block/nbd.c: Add " Lukas Straub
2020-08-27 10:31 ` Daniel P. Berrangé
2020-08-04 8:11 ` [PATCH v7 3/8] chardev/char-socket.c: " Lukas Straub
2020-08-27 10:32 ` Daniel P. Berrangé
2020-08-04 8:11 ` [PATCH v7 4/8] migration: " Lukas Straub
2020-08-27 10:39 ` Daniel P. Berrangé
2020-08-04 8:11 ` [PATCH v7 5/8] io/channel-tls.c: make qio_channel_tls_shutdown thread-safe Lukas Straub
2020-08-04 8:11 ` [PATCH v7 6/8] io: Document thread-safety of qio_channel_shutdown Lukas Straub
2020-08-04 8:11 ` [PATCH v7 7/8] MAINTAINERS: Add myself as maintainer for yank feature Lukas Straub
2020-08-04 8:12 ` [PATCH v7 8/8] tests/test-char.c: Wait for the chardev to connect in char_socket_client_dupid_test Lukas Straub
2020-08-27 10:30 ` Daniel P. Berrangé
2020-08-18 12:26 ` [PATCH v7 0/8] Introduce 'yank' oob qmp command to recover from hanging qemu Lukas Straub
2020-08-27 8:42 ` Lukas Straub
2020-08-27 10:41 ` Daniel P. Berrangé
2020-08-27 14:18 ` Markus Armbruster
2020-08-27 17:58 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200904141312.185a20d5@luklap \
--to=lukasstraub2@web.de \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.