Re: [PATCH 02/13] qcrypto-luks: implement encryption key management

[Markus Armbruster]

Markus Armbruster <address@hidden> writes:

> Kevin Wolf <address@hidden> writes:
>
>> Am 05.02.2020 um 11:03 hat Markus Armbruster geschrieben:
>>> Kevin Wolf <address@hidden> writes:
[...]
>>> > Adding a key gets more complicated with your proposed interface because
>>> > state must be set explicitly now whereas before it was derived
>>> > automatically from the fact that if you give a key, only active makes
>>> > sense.
>>> 
>>> The explicitness could be viewed as an improvement :)
>>
>> Not really. I mean, I really know to appreciate the advantages of
>> -blockdev where needed, but usually I don't want to type all that stuff
>> for the most common tasks. qemu-img amend is similar.
>>
>> For deleting, I might actually agree that explicitness is an
>> improvement, but for creating it's just unnecessary verbosity.
>>
>>> If you'd prefer implicit here: Max has patches for making union tags
>>> optional with a default.  They'd let you default active to true.
>>
>> I guess this would improve the usability in this case.

Thinking and writing in the "Making QEMU easier for management tools and
applications" monster thread have made me realize we're mixing up two
aspects that ought to be kept separate: machine-friendly QMP and
human-friendly CLI.

You argue that

    $ qemu-img amend -o encrypt.keys.0.new-secret=sec0 test.qcow2

is nicer than

    $ qemu-img amend -o encrypt.keys.0.state=active,encrypt.keys.0.secret=sec0 
test.qcow2

and you do have a point: humans want their CLI terse.  Redundancy is
unwanted, except perhaps to protect users from dangerous accidents.  In
this example, state=active is redundant when a secret is given, because
anything else would be an error.

In QMP, however, we like things simple and explicit, and we eschew
magic.

This particular magic might just be simple enough to be acceptable in
QMP.  We'd "merely" have to support explicit defaults in the schema (a
clear improvement if you ask me), and optional union tags (tolerable as
long as the default comes from the schema, I guess).

My point is: QAPI schema design *must* focus on QMP and nothing else.
If we try to serve both QMP and human-friendly CLI, we'll likely botch
both.

I believe a truly human-friendly CLI requires more than just
human-friendly concrete syntax for QMP.  Same as HMP, really.