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

[Max Reitz]

On 2018-08-20 08:38, Markus Armbruster wrote:
> Max Reitz <address@hidden> writes:
> 
>> On 2018-08-16 08:40, Markus Armbruster wrote:

[...]

>> (And technically you need a string filename to point to when doing
>> block-commit (Kevin sent patches to remedy this, though), so that could
>> be called an application as well.)
>>
>>> Having image file headers point to other images is not as simple as it
>>> may look at first glance.  The basic case of image format plus plain
>>> filename (not containing '/') is straightforward enough.  But if I make
>>> the filename absolute (with a leading '/'), the image becomes less easy
>>> to move to another machine.
>>
>> That assumes that we correctly implement relative backing file names.
>> Believe me, we don't.
>>
>> For example, say you did this:
>>
>> $ qemu-img create -f qcow2 foo/bot.qcow2 1M
>> $ qemu-img create -f qcow2 -b bot.qcow2 foo/mid.qcow2
>> $ qemu-img create -f qcow2 -b mid.qcow2 foo/top.qcow2
>>
>> Now try committing top to mid.
>>
>> You're right, it's impossible right now.
>>
>> (Not via -b mid.qcow2, nor via -b foo/mid.qcow2, nor via
>> $PWD/foo/mid.qcow2.  Short of CD-ing to foo/ and then committing to
>> mid.qcow2, it's just impossible.)
>>
>> ((I've send patches to fix this, but still, it's not like we even got
>> the case right that's "straightforward enough". :-)))
> 
> Wait, I carefully defined "straightforward enough" as "filename not
> containing '/'".  Did we manage to screw that up, too?

Well, you were talking about the backing filename.  In the example given
above, none of the backing filenames contain a '/'. O:-)

>>> Similarly, certain Ceph configuration bits may make no sense on another
>>> machine, and putting them into an image file header may not be a good
>>> idea.
>>
>> On one hand, sure.  Adding json:{} filenames really wasn't one of my
>> finest hours.  It looked like a simple enough idea at the time, but
>> they're just not really useful and just keep on biting us.
>>
>> On another, well, but they may indeed make sense on another machine.
>> It's like specifying an ssh URL (or absolute mount point on a local
>> machine, like you describe above).  It may make sense to some (say, you
>> have a global "content server" or something), so, well.
>>
>> I mean, our ideal model is that the user just configures the whole
>> backing chain at runtime and nothing is our fault.  At least that's my
>> ideal model.  It's always the management layer's fault. O:-)
> 
> Hi management layer, I got another buck for you!
> 
> I'm currently leaning towards regarding an image header's references to
> other images as a convenience feature for users.  Saves restating the
> "obvious" (appreciated), until the obvious becomes wrong, possibly
> creating confusion (generally less appreciated).  I think having them is
> a perfectly reasonable tradeoff overall at least for simple cases.
> However, I suspect the more complex things get, the more the value of
> "obvious" diminishes, and the more likely confusion becomes.  Mix of
> observation and speculation, not a call for action.

That's how I'd like to look at it, too, but I'm not sure how reasonable
it is.  Well, it is reasonable as long as we can clearly define for
which use cases it simply isn't enough (*cough* the ones where you need
json:{} *cough*), but I suppose that's too late now.  With json:{} you
unfortunately can shoehorn everything into your image header...
(Which was the point, but you know, path to hell and good intentions and
so on.)

Max

signature.asc
Description: OpenPGP digital signature