Re: [Qemu-devel] [RFC PATCH] rbd: Don't convert keypairs to JSON and back

[Jeff Cody <jcody@redhat.com>]

On Wed, Jul 25, 2018 at 05:01:44PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jul 25, 2018 at 10:56:48AM -0500, Eric Blake wrote:
> > On 07/25/2018 10:10 AM, Markus Armbruster wrote:
> > > qemu_rbd_parse_filename() builds a keypairs QList, converts it to JSON, and
> > > stores the resulting QString in a QDict.
> > > 
> > > qemu_rbd_co_create_opts() and qemu_rbd_open() get the QString from the
> > > QDict, pass it to qemu_rbd_set_keypairs(), which converts it back into
> > > a QList.
> > > 
> > > Drop both conversions, store the QList instead.
> > > 
> > > This affects output of qemu-img info.  Before this patch:
> > > 
> > >      $ qemu-img info rbd:rbd/testimg.raw:mon_host=192.168.15.180:rbd_cache=true:conf=/tmp/ceph.conf
> > >      [junk printed by Ceph library code...]
> > >      image: json:{"driver": "raw", "file": {"pool": "rbd", "image": "testimg.raw", "conf": "/tmp/ceph.conf", "driver": "rbd", "=keyvalue-pairs": "[\"mon_host\", \"192.168.15.180\", \"rbd_cache\", \"true\"]"}}
> > >      [more output, not interesting here]
> > > 
> > > After this patch, we get
> > > 
> > >      image: json:{"driver": "raw", "file": {"pool": "rbd", "image": "testimg.raw", "conf": "/tmp/ceph.conf", "driver": "rbd", "=keyvalue-pairs": ["mon_host", "192.168.15.180", "rbd_cache", "true"]}}
> > > 
> > > The value of member "=keyvalue-pairs" changes from a string containing
> > > a JSON array to that JSON array.  That's an improvement of sorts.  However:
> > > 
> > > * Should "=keyvalue-pairs" even be visible here?  It's supposed to be
> > >    purely internal...
> > 
> > I'd argue that since it is supposed to be internal (as evidenced by the
> > leading '=' that does not name a normal variable), changing it doesn't hurt
> > stability. But yes, it would be nicer if we could filter it entirely so that
> > it does not appear in json: output, if it doesn't truly affect the contents
> > that the guest would see.
> 
> If it appears in the json: output, then that means it could get written
> into qcow2 headers as a backing file name, which would make it ABI
> sensitive. This makes it even more important to filter it if it is supposed
> to be internal only, with no ABI guarantee.
> 

It's been present for a couple releases (counting 3.0); is it safe to
assume that, although it could be present in the qcow2 headers, that it will
not break anything by altering it or removing it?

If so, and we are comfortable changing the output the way this patch does
(technically altering ABI anyway), we might as well go all the way and
filter it out completely.  That would be preferable to cleaning up the json
output of the internal key/value pairs, IMO.

-Jeff