All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Jeff Cody <jcody@redhat.com>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, jsnow@redhat.com, qemu-stable@nongnu.org,
	qemu-block@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/2] block/rbd: Attempt to parse legacy filenames
Date: Tue, 11 Sep 2018 13:03:44 -0500	[thread overview]
Message-ID: <0385dca9-60e7-388c-56e1-fbf2b75ff8f0@redhat.com> (raw)
In-Reply-To: <570e8585c94d6f1bd7406ce5d35f68a82b6ea28c.1536642773.git.jcody@redhat.com>

On 9/11/18 12:15 AM, 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.
> 
> This approach has a potential drawback: if for some reason there are
> some options supplied the new way, and some the old way, we may not
> catch all the old options if they are not required options (since it
> won't cause the initial failure).

No one should be mixing new and old, though.

> 
> Signed-off-by: Jeff Cody <jcody@redhat.com>
> ---
>   block/rbd.c | 30 +++++++++++++++++++++++++++---
>   1 file changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/block/rbd.c b/block/rbd.c
> index a8e79d01d2..bce86b8bde 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
> @@ -685,7 +685,7 @@ static int qemu_rbd_open(BlockDriverState *bs, QDict *options, int flags,
>       BlockdevOptionsRbd *opts = NULL;
>       const QDictEntry *e;
>       Error *local_err = NULL;
> -    char *keypairs, *secretid;
> +    char *keypairs, *secretid, *filename;
>       int r;
>   
>       keypairs = g_strdup(qdict_get_try_str(options, "=keyvalue-pairs"));
> @@ -700,8 +700,32 @@ static int qemu_rbd_open(BlockDriverState *bs, QDict *options, int flags,
>   
>       r = qemu_rbd_convert_options(bs, options, &opts, &local_err);
>       if (local_err) {
> -        error_propagate(errp, local_err);
> -        goto out;

Oh, my comment about simplifying this in 1/2 is probably moot, now that 
you are doing a lot more based on local_err rather than just blindly 
propagating it.

> +        /* 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 */
> +        Error *parse_err = NULL;
> +
> +        filename = g_strdup(qdict_get_try_str(options, "filename"));

You already spotted your leak.

> +        qdict_del(options, "filename");
> +
> +        qemu_rbd_parse_filename(filename, options, NULL);
> +
> +        g_free(keypairs);

Wait. Why are you unilaterally freeing any previously-parsed keypairs in 
favor of the ones parsed out of the filename?  I'd rather that we insist 
on only old behavior, or only new, and not some mix.  Thus, if we 
already detected keypairs at all, we should declare this situation as an 
error, rather than throwing them away.

> +        keypairs = g_strdup(qdict_get_try_str(options, "=keyvalue-pairs"));
> +        if (keypairs) {
> +            qdict_del(options, "=keyvalue-pairs");
> +        }
> +
> +        r = qemu_rbd_convert_options(bs, options, &opts, &parse_err);
> +        if (parse_err) {
> +            /* if the second attempt failed, pass along the original error
> +             * message for the current format */
> +            error_propagate(errp, local_err);
> +            error_free(parse_err);
> +            goto out;
> +        }
>       }

The idea of trying two parses makes sense, but I'm hoping v2 better 
handles the case of detecting bad attempts to mix-and-match behavior. 
Furthermore, is there an iotests that you can modify (or add) as a 
regression test for this working the way we want?

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

  parent reply	other threads:[~2018-09-11 18:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-11  5:15 [Qemu-devel] [PATCH 0/2] block/rbd: enable filename parsing on open Jeff Cody
2018-09-11  5:15 ` [Qemu-devel] [PATCH 1/2] block/rbd: pull out qemu_rbd_convert_options Jeff Cody
2018-09-11 17:50   ` Eric Blake
2018-09-11 18:06   ` John Snow
2018-09-11  5:15 ` [Qemu-devel] [PATCH 2/2] block/rbd: Attempt to parse legacy filenames Jeff Cody
2018-09-11 17:53   ` Jeff Cody
2018-09-11 18:03   ` Eric Blake [this message]
2018-09-11 18:28     ` Jeff Cody
2018-09-11 18:22   ` John Snow
2018-09-11 18:37     ` Jeff Cody
2018-09-11 18:39       ` John Snow
2018-09-12 10:38       ` Kevin Wolf
2018-09-12 12:42         ` Jeff Cody
2018-09-12 12:49           ` Jeff Cody

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=0385dca9-60e7-388c-56e1-fbf2b75ff8f0@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jcody@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@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 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.