From: Max Reitz <mreitz@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>, qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-block@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
"John Snow" <jsnow@redhat.com>
Subject: Re: [PATCH v8 05/14] block/amend: refactor qcow2 amend options
Date: Tue, 16 Jun 2020 15:23:34 +0200 [thread overview]
Message-ID: <32faa102-737e-320e-fe7a-501965719f07@redhat.com> (raw)
In-Reply-To: <20200608094030.670121-6-mlevitsk@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1269 bytes --]
On 08.06.20 11:40, Maxim Levitsky wrote:
> Some qcow2 create options can't be used for amend.
> Remove them from the qcow2 create options and add generic logic to detect
> such options in qemu-img
>
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Last week (when I was about to prepare a pull request), I noticed that
this patch breaks the iotests 134 and 158 for qcow (v1). That’s because
as of this patch, qcow2 has a different order of creation options than qcow.
We could easily fix this by moving HEAD^:134.out and HEAD^:158.out to
134.out.qcow and 158.out.qcow, respectively, and HEAD:134.out and
HEAD:158.out to 134.out.qcow2 and 158.out.qcow2, respectively.
But the underlying problem is a greater one: The order of creation
options isn’t fixed between different formats, so I think
_filter_img_create should sort it so it’s the same for all.
To do so, I just sent the “iotests: Make _filter_img_create more active”
series. We could put that underneath your series and then the problem
would be fixed, too (and we could drop some of the hunks from this
patch, because the option order wouldn’t change for any test that uses
_filter_img_create).
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-06-16 13:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-08 9:40 [PATCH v8 00/14] LUKS: encryption slot management using amend interface Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 01/14] qcrypto/core: add generic infrastructure for crypto options amendment Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 02/14] qcrypto/luks: implement encryption key management Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 03/14] block/amend: add 'force' option Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 04/14] block/amend: separate amend and create options for qemu-img Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 05/14] block/amend: refactor qcow2 amend options Maxim Levitsky
2020-06-16 13:23 ` Max Reitz [this message]
2020-06-08 9:40 ` [PATCH v8 06/14] block/crypto: rename two functions Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 07/14] block/crypto: implement the encryption key management Maxim Levitsky
2020-06-08 12:14 ` Max Reitz
2020-06-16 13:57 ` Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 08/14] block/qcow2: extend qemu-img amend interface with crypto options Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 09/14] iotests: filter few more luks specific create options Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 10/14] iotests: qemu-img tests for luks key management Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 11/14] block/core: add generic infrastructure for x-blockdev-amend qmp command Maxim Levitsky
2020-07-08 12:33 ` Gerd Hoffmann
2020-07-08 13:06 ` Maxim Levitsky
2020-07-08 13:47 ` Gerd Hoffmann
2020-07-08 14:23 ` Gerd Hoffmann
2020-07-08 16:11 ` Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 12/14] block/crypto: implement blockdev-amend Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 13/14] block/qcow2: " Maxim Levitsky
2020-06-08 9:40 ` [PATCH v8 14/14] iotests: add tests for blockdev-amend Maxim Levitsky
2020-06-08 11:54 ` [PATCH v8 00/14] LUKS: encryption slot management using amend interface no-reply
2020-06-08 12:15 ` Max Reitz
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=32faa102-737e-320e-fe7a-501965719f07@redhat.com \
--to=mreitz@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).