From: Eric Blake <eblake@redhat.com>
To: Jeff Cody <jcody@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, qemu-stable@nongnu.org, jsnow@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 2/3] block/rbd: Attempt to parse legacy filenames
Date: Tue, 11 Sep 2018 16:05:45 -0500 [thread overview]
Message-ID: <2cfec9c2-9619-b313-13f9-57bbd1be58ec@redhat.com> (raw)
In-Reply-To: <c749883a9bce0234fff0813c1e1ec5a893328049.1536698311.git.jcody@redhat.com>
On 9/11/18 3:43 PM, Jeff Cody wrote:
> When we converted rbd to get rid of the older key/value-centric
> encoding format, we broke compatibility with image files with backing
> file strings encoded in the old format.
>
> This leaves a bit of an ugly conundrum, and a hacky solution.
>
> If the initial attempt to parse the "proper" options fails, it assumes
> that we may have an older key/value encoded filename. Fall back to
> attempting to parse the filename, and extract the required options from
> it. If that fails, pass along the original error message.
>
> We do not support mixed modern usage alongside legacy keyvalue pair
> usage.
>
> A deprecation warning has been added, although care should be taken
> when actually deprecating since the impact is not limited to
> commandline or qapi usage, but also opening existing images.
>
> Signed-off-by: Jeff Cody <jcody@redhat.com>
> ---
> block/rbd.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 51 insertions(+), 2 deletions(-)
Where's the patch to qemu/qemu-deprecated.texi to mention the new
message and our advice on upgrading images to avoid triggering it?
>
> diff --git a/block/rbd.c b/block/rbd.c
> index b199450f9f..5090e4f662 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
> @@ -678,6 +678,33 @@ static int qemu_rbd_convert_options(QDict *options, BlockdevOptionsRbd **opts,
> return 0;
> }
>
> +static int qemu_rbd_attempt_legacy_options(QDict *options,
> + BlockdevOptionsRbd **opts,
> + char **keypairs)
> +{
> + char *filename;
> + int r;
> +
> + filename = g_strdup(qdict_get_try_str(options, "filename"));
> + if (!filename) {
> + return -EINVAL;
> + }
> + qdict_del(options, "filename");
> +
> + qemu_rbd_parse_filename(filename, options, NULL);
Intentionally ignoring errors here,
> +
> + /* keypairs freed by caller */
> + *keypairs = g_strdup(qdict_get_try_str(options, "=keyvalue-pairs"));
> + if (*keypairs) {
> + qdict_del(options, "=keyvalue-pairs");
> + }
> +
> + r = qemu_rbd_convert_options(options, opts, NULL);
and here. I guess we'll see how the caller is expecting things to behave.
> +
> + g_free(filename);
> + return r;
> +}
> +
> static int qemu_rbd_open(BlockDriverState *bs, QDict *options, int flags,
> Error **errp)
> {
> @@ -700,8 +727,30 @@ static int qemu_rbd_open(BlockDriverState *bs, QDict *options, int flags,
>
> r = qemu_rbd_convert_options(options, &opts, &local_err);
> if (local_err) {
> - error_propagate(errp, local_err);
> - goto out;
> + /* If keypairs are present, that means some options are present in
> + * the modern option format. Don't attempt to parse legacy option
> + * formats, as we won't support mixed usage. */
> + if (keypairs) {
> + error_propagate(errp, local_err);
> + goto out;
> + }
> +
> + /* If the initial attempt to convert and process the options failed,
> + * we may be attempting to open an image file that has the rbd options
> + * specified in the older format consisting of all key/value pairs
> + * encoded in the filename. Go ahead and attempt to parse the
> + * filename, and see if we can pull out the required options. */
> + r = qemu_rbd_attempt_legacy_options(options, &opts, &keypairs);
> + if (r < 0) {
> + error_propagate(errp, local_err);
> + goto out;
> + }
> + /* Take care whenever deciding to actually deprecate; once this ability
> + * is removed, we will not be able to open any images with legacy-styled
> + * backing image strings. */
> + error_report("RBD options encoded in the filename as keyvalue pairs "
> + "is deprecated. Future versions may cease to parse "
> + "these options in the future.");
Okay, so you're making a best-effort fallback to scrape out any
remaining keyvalue pairs. If there was no filename (and hence no
keyvalue pairs populated), we know up front that we lack enough
information, so attempt_legacy_options() returns failure right away; if
there was a filename, we don't know if we got all the required options
(so ignoring errors was okay) - that will be up to later code to
decipher, after we emit our warning that we already relied on legacy
options (if the later code has all it needed, then only the warning is
emitted; if later code fails, the user now has the warning in addition
to the later failure message to help them resolve their images).
A bit confusing how it all fits together, but it seems to work out in
the end.
Reviewed-by: Eric Blake <eblake@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2018-09-11 21:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 20:43 [Qemu-devel] [PATCH v2 0/3] block/rbd: enable filename parsing on open Jeff Cody
2018-09-11 20:43 ` [Qemu-devel] [PATCH v2 1/3] block/rbd: pull out qemu_rbd_convert_options Jeff Cody
2018-09-11 20:43 ` [Qemu-devel] [PATCH v2 2/3] block/rbd: Attempt to parse legacy filenames Jeff Cody
2018-09-11 21:05 ` Eric Blake [this message]
2018-09-11 21:23 ` Jeff Cody
2018-09-11 20:43 ` [Qemu-devel] [PATCH v2 3/3] block/rbd: add iotest for rbd legacy keyvalue filename parsing Jeff Cody
2018-09-11 21:11 ` Eric Blake
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=2cfec9c2-9619-b313-13f9-57bbd1be58ec@redhat.com \
--to=eblake@redhat.com \
--cc=jcody@redhat.com \
--cc=jsnow@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@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).