From: Jeff Cody <jcody@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, armbru@redhat.com,
eblake@redhat.com
Subject: Re: [Qemu-devel] [PATCH 4/4] block/rbd: Add blockdev-add support
Date: Mon, 27 Feb 2017 08:38:24 -0500 [thread overview]
Message-ID: <20170227133824.GE25637@localhost.localdomain> (raw)
In-Reply-To: <20170227133046.GK18219@redhat.com>
On Mon, Feb 27, 2017 at 01:30:46PM +0000, Daniel P. Berrange wrote:
> On Mon, Feb 27, 2017 at 08:18:59AM -0500, Jeff Cody wrote:
> > On Mon, Feb 27, 2017 at 09:31:21AM +0000, Daniel P. Berrange wrote:
> > > On Mon, Feb 27, 2017 at 02:36:13AM -0500, Jeff Cody wrote:
> > > > On Mon, Feb 27, 2017 at 02:30:41AM -0500, Jeff Cody wrote:
> > > > > Signed-off-by: Jeff Cody <jcody@redhat.com>
> > > > > ---
> > > > > qapi/block-core.json | 47 ++++++++++++++++++++++++++++++++++++++++++++---
> > > > > 1 file changed, 44 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > > > > index 5f82d35..08a1419 100644
> > > > > --- a/qapi/block-core.json
> > > > > +++ b/qapi/block-core.json
> > > > > @@ -2111,6 +2111,7 @@
> > > > > # @replication: Since 2.8
> > > > > # @ssh: Since 2.8
> > > > > # @iscsi: Since 2.9
> > > > > +# @rbd: Since 2.9
> > > > > #
> > > > > # Since: 2.0
> > > > > ##
> > > > > @@ -2120,7 +2121,7 @@
> > > > > 'host_device', 'http', 'https', 'iscsi', 'luks', 'nbd', 'nfs',
> > > > > 'null-aio', 'null-co', 'parallels', 'qcow', 'qcow2', 'qed',
> > > > > 'quorum', 'raw', 'replication', 'ssh', 'vdi', 'vhdx', 'vmdk',
> > > > > - 'vpc', 'vvfat' ] }
> > > > > + 'vpc', 'vvfat', 'rbd' ] }
> > > > >
> > > > > ##
> > > > > # @BlockdevOptionsFile:
> > > > > @@ -2376,7 +2377,6 @@
> > > > > 'path': 'str',
> > > > > '*user': 'str' } }
> > > > >
> > > > > -
> > > > > ##
> > > > > # @BlkdebugEvent:
> > > > > #
> > > > > @@ -2666,6 +2666,47 @@
> > > > > '*timeout': 'int' } }
> > > > >
> > > > > ##
> > > > > +# @BlockdevOptionsRbd:
> > > > > +#
> > > > > +# @pool: Ceph pool name
> > > > > +#
> > > > > +# @image: Image name in the Ceph pool
> > > > > +#
> > > > > +# @conf: # optional path to Ceph configuration file. Values
> > > > > +# in the configuration file will be overridden by
> > > > > +# options specified via QAPI.
> > > > > +#
> > > > > +# @snapshot: #optional Ceph snapshot name
> > > > > +#
> > > > > +# @rbd-id: #optional Ceph id name
> > > > > +#
> > > > > +# @password-secret: #optional The ID of a QCryptoSecret object providing
> > > > > +# the password for the login.
> > > > > +#
> > > > > +# @keyvalue-pairs: #optional string containing key/value pairs for
> > > > > +# additional Ceph configuration, not including "id" or "conf"
> > > > > +# options. This can be used to specify any of the options
> > > > > +# that Ceph supports. The format is of the form:
> > > > > +# key1=value1:key2=value2:[...]
> > > > > +#
> > > > > +# Special characters such as ":" and "=" can be escaped
> > > > > +# with a '\' character, which means the QAPI needs an
> > > > > +# extra '\' character to pass the needed escape character.
> > > > > +# For example:
> > > > > +# "keyvalue-pairs": "mon_host=127.0.0.1\\:6321"
> > > > > +#
> > > >
> > > > This is the key / value pair issue mentioned in the cover letter. Encoding
> > > > all the options as a string like this is ugly. What is the preference on
> > > > how to handle these via QAPI, when the actual key and value pairs could be
> > > > anything? Talking with Markus on IRC, one option he mentioned was an array
> > > > of a generic struct of 'key' and 'value' pairs.
> > > >
> > > > Do the libvirt folks have any interface preferences here?
> > >
> > > IMHO, we should formally model each option that we need to be able to provide
> > > and *not* provide any generic passthrough feature in QAPI.
> > >
> > > Particularly for the server hostname/port, we should have the same QAPI
> > > modelling approach that we did for other network protocols.
> > >
> > >
> >
> > That is a sane position to take, but the problem is I really have no idea
> > all the options to include or not include here.
>
> Libvirt relies on the following
>
> - id - to provide the username
> - mon_host - to provide the list of host+ports
> - auth_supported - to provide the list of authentication schemes to try
> - conf - to proide the ceph config file
>
>
> > However, maybe it doesn't matter, at least for 2.9 - for the QAPI command,
> > we could drop the extra arguments completely (i.e., just drop the
> > keyvalue-pairs argument, above). The extra options could still be set via a
> > config file passed in via 'conf', and in release > 2.9 we can gradually (or
> > not-so-gradually) add in additional options directly supported via QAPI.
> >
> > The filename parsing would remain the same, for backwards compatibility, of
> > course.
> >
> > Does this sound reasonable to you?
>
> If we support the pieces libvirt needs, then I've no objection to dropping
> the rest.
>
I'll add in mon_host and auth_supported, then. Then we'll rely on the
config file for unlisted options, and revisit new options in later releases.
Thanks,
Jeff
next prev parent reply other threads:[~2017-02-27 13:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-27 7:30 [Qemu-devel] [PATCH 0/4] RBD: blockdev-add Jeff Cody
2017-02-27 7:30 ` [Qemu-devel] [PATCH 1/4] block/rbd: don't copy strings in qemu_rbd_next_tok() Jeff Cody
2017-02-27 16:39 ` Markus Armbruster
2017-02-27 18:07 ` Jeff Cody
2017-02-27 7:30 ` [Qemu-devel] [PATCH 2/4] block/rbd: code movement Jeff Cody
2017-02-27 9:28 ` Daniel P. Berrange
2017-02-27 13:14 ` Jeff Cody
2017-02-27 7:30 ` [Qemu-devel] [PATCH 3/4] block/rbd: parse all options via bdrv_parse_filename Jeff Cody
2017-02-27 7:30 ` [Qemu-devel] [PATCH 4/4] block/rbd: Add blockdev-add support Jeff Cody
2017-02-27 7:36 ` Jeff Cody
2017-02-27 9:31 ` Daniel P. Berrange
2017-02-27 13:18 ` Jeff Cody
2017-02-27 13:30 ` Daniel P. Berrange
2017-02-27 13:38 ` Jeff Cody [this message]
2017-02-27 13:45 ` Daniel P. Berrange
2017-02-27 15:27 ` 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=20170227133824.GE25637@localhost.localdomain \
--to=jcody@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@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).