qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Nir Soffer <nirsof@gmail.com>, qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, kwolf@redhat.com, mreitz@redhat.com,
	rjones@redhat.com, qemu-block@nongnu.org,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] qemu-iotests: Test new qemu-nbd --nolist option
Date: Tue, 17 Apr 2018 14:56:27 -0500	[thread overview]
Message-ID: <d66868b2-591b-28ce-d7dd-e8af3f8fc6cd@redhat.com> (raw)
In-Reply-To: <20180413192605.2145-4-nirsof@gmail.com>

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

On 04/13/2018 02:26 PM, Nir Soffer wrote:
> Add new test module for tesing the --nolist option.
> 
> Signed-off-by: Nir Soffer <nirsof@gmail.com>
> ---

> +iotests.log('Check that listing exports is allowed by default')
> +disk, nbd_sock = iotests.file_path('disk1', 'nbd-sock1')
> +iotests.qemu_img_create('-f', iotests.imgfmt, disk, '1m')
> +iotests.qemu_nbd('-k', nbd_sock, '-f', iotests.imgfmt, '-x', 'export', disk)
> +out = iotests.run('nbd-client', '-l', '--unix', nbd_sock)

Should we really be relying on the third-party nbd-client to be
installed?  Would it not be better to teach our own NBD client to learn
how to do interesting things over NBD?  Your use case of listing the
output of NBD_OPT_LIST is one, but another that readily comes to mind is
listing the possibilities of NBD_OPT_LIST_META_CONTEXT that just went
into 2.12.  Maybe making 'qemu-img info' give more details when
connecting to an NBD server, compared to what is normally needed just
for connecting to an export on that server?

Additionally, once we merge in Vladimir's work to expose persistent
dirty bitmaps via NBD_OPT_SET_META_CONTEXT/NBD_CMD_BLOCK_STATUS, it
would be nice to have an in-tree tool for reading out the context
information of an NBD export, perhaps extending what 'qemu-img map' can
already do (Vladimir already mentioned that he only implemented the
server side, and left the client side for an out-of-tree solution [1],
although I'm wondering if that is still the wisest course of action).

[1] https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg05701.html

> +
> +assert 'export' in out.splitlines(), 'Export not in %r' % out
> +
> +iotests.log('Check that listing exports is forbidden with --nolist')
> +disk, nbd_sock = iotests.file_path('disk2', 'nbd-sock2')
> +iotests.qemu_img_create('-f', iotests.imgfmt, disk, '1m')
> +iotests.qemu_nbd('-k', nbd_sock, '-f', iotests.imgfmt, '-x', 'secret',
> +                 '--nolist', disk)
> +
> +# nbd-client fails when listing is not allowed, but lets not depend on 3rd

s/lets/let's/

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

  reply	other threads:[~2018-04-17 19:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 19:26 [Qemu-devel] [PATCH 0/3] qemu-nbd: Disallow listing exports Nir Soffer
2018-04-13 19:26 ` [Qemu-devel] [PATCH 1/3] nbd: Add option to disallow " Nir Soffer
2018-04-13 21:07   ` Richard W.M. Jones
2018-04-16 10:31   ` Daniel P. Berrangé
2018-04-16 10:53     ` Richard W.M. Jones
2018-04-16 11:00       ` Daniel P. Berrangé
2018-04-17 19:47         ` Eric Blake
2018-04-17 19:41   ` Eric Blake
2018-04-13 19:26 ` [Qemu-devel] [PATCH 2/3] iotests.py: Add helper for running commands Nir Soffer
2018-04-13 19:26 ` [Qemu-devel] [PATCH 3/3] qemu-iotests: Test new qemu-nbd --nolist option Nir Soffer
2018-04-17 19:56   ` Eric Blake [this message]
2018-04-18  9:43     ` Vladimir Sementsov-Ogievskiy

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=d66868b2-591b-28ce-d7dd-e8af3f8fc6cd@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=nirsof@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=vsementsov@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).