From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ciLOG-0008Q5-Ma for qemu-devel@nongnu.org; Mon, 27 Feb 2017 08:31:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ciLOF-00063X-7P for qemu-devel@nongnu.org; Mon, 27 Feb 2017 08:31:00 -0500 Date: Mon, 27 Feb 2017 13:30:46 +0000 From: "Daniel P. Berrange" Message-ID: <20170227133046.GK18219@redhat.com> Reply-To: "Daniel P. Berrange" References: <08786526aec147544588ab3e885a984e7d0d1c69.1488180142.git.jcody@redhat.com> <20170227073613.GB25637@localhost.localdomain> <20170227093121.GD18219@redhat.com> <20170227131859.GD25637@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170227131859.GD25637@localhost.localdomain> Subject: Re: [Qemu-devel] [PATCH 4/4] block/rbd: Add blockdev-add support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, armbru@redhat.com, eblake@redhat.com 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 > > > > --- > > > > 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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|