On 04/06/2018 03:04 AM, Kevin Wolf wrote: > Am 05.04.2018 um 19:06 hat Kevin Wolf geschrieben: >> The legacy command line syntax supports a "password-secret" option that >> allows to pass an authentication key to Ceph. This was not supported in >> QMP so far. >> >> This patch introduces authentication options in the QAPI schema, makes >> them do the corresponding rados_conf_set() calls and adds compatibility >> code that translates the old "password-secret" option both for opening >> and creating images to the new set of options. >> >> Note that the old option didn't allow to explicitly specify the set of >> allowed authentication schemes. The compatibility code assumes that if >> "password-secret" is given, only the cephx scheme is allowed. If it's >> missing, both none and cephx are allowed because the configuration file >> could still provide a key. > > There is another problem here that suggests that maybe this is not the > right QAPI schema after all: The defaults needed for command line > compatibility and those promised in the QAPI schema are conflicting. > > The required command line behaviour is as described above: > > * password-secret given: only cephx > * no options given: cephx, none > > The desired QMP default behaviour is: > > * auth-cephx given: allow cephx > * auth-none given: allow none > * both given: allow both > * no options given: error > > In .bdrv_open() there is no way to distinguish the "no options given" of > the command line from that of QMP. The current implementation allows > everything if no options are given, i.e. it keeps existing command lines > working, but it doesn't correctly implement the behaviour described in > the QAPI schema.
Can we use a QAPI alternate with an explicit JSON null for the command
line 'no options given' case?
>
> I don't think changing the description of the QAPI schema would be a
> good idea, it would be a rather surprising interface.
>
>> Signed-off-by: Kevin Wolf <kw...@redhat.com>
>> ---
>>
>> This doesn't actually work correctly yet because the way that options
>> are passed through the block layer (QAPI -> QemuOpts -> QDict). Before
>> we fix or hack around this, let's make sure this is the schema that we
>> want.
Can we skip the intermediate QemuOpts? If we can go straight from
command line to QDict using just QAPI, won't that give us what we really
need?
>>
>> The two known problems are:
>>
>> 1. QDict *options in qemu_rbd_open() may contain options either in their
>> proper QObject types (if passed from blockdev-add) or as strings
>> (-drive). Both forms can be mixed in the same options QDict.
>>
>> rbd uses the keyval visitor to convert the options into a QAPI
>> object. This means that it requires all options to be strings. This
>> patch, however, introduces a bool property, so the visitor breaks
>> when it gets its input from blockdev-add.
>>
>> Options to hack around the problem:
>>
>> a. Do an extra conversion step or two and go through QemuOpts like
>> some other block drivers. When I offered something like this to
>> Markus a while ago in a similar case, he rejected the idea.
>>
>> b. Introduce a qdict_stringify_entries() that just does what its name
>> says. It would be called before the running keyval visitor so that
>> only strings will be present in the QDict.
>>
>> c. Do a local one-off hack that checks if the entry with the key
>> "auth-none" is a QBool, and if so, overwrite it with a string. The
>> problem will reappear with the next non-string option.
>>
>> (d. Get rid of the QDict detour and work only with QAPI objects
>> everywhere. Support rbd authentication only in QEMU 4.0.)
Oh, even one step further than just avoiding QemuOpts, but using REAL
types everywhere in the block layer! It might be a nice cleanup, but it
would probably take a lot of effort in the meantime to get to that point?
>>
>> 2. The proposed schema allows 'auth-cephx': {} as a valid option with
>> the meaning that the cephx authentication scheme is enabled, but no
>> key is given (e.g. it is taken from the config file).
>>
>> However, an empty dict cannot currently be represented by flattened
>> QDicts. We need to find a way to enable this. I think this will be
>> externally visible because it directly translates into the dotted
>> syntax of -blockdev, so we may want to be careful.
Can we just require users to give -blockdev with the JSON format (rather
than dotted format) when they need to use that particular feature on the
command line?
>>
>> Any thoughts on the proposed QAPI schema or the two implementation
>> problems are welcome.
>
> Kevin
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
