Re: [Qemu-devel] [RFC][BROKEN] rbd: Allow configuration of authentication scheme

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

Am 18.04.2018 um 16:16 hat Eric Blake geschrieben:
> On 04/18/2018 08:50 AM, Kevin Wolf wrote:
> 
> >>> @@ -3195,6 +3215,8 @@
> >>>              '*conf': 'str',
> >>>              '*snapshot': 'str',
> >>>              '*user': 'str',
> >>> +            '*auth-none': 'bool',
> >>> +            '*auth-cephx': 'RbdAuthCephx',
> >>>              '*server': ['InetSocketAddressBase'] } }
> >>
> >> Would it be better to have this be a flat union with 'auth' with enum
> >> values 'none', 'cephx', 'both' as a discriminator that determines which
> >> additional fields can be present?  Or does that require that we first
> >> fix the QAPI generator to allow nesting a flat union within another flat
> >> union (probably doable, just no one has needed it before now)?  Is it
> >> also time to improve the QAPI generator to allow a default value to the
> >> discriminator field, rather than requiring the field to be present?
> > 
> > Both options can be enabled at the same time, so that the client
> > connects to a server no matter whether it does 'cephx' authentication or
> > only 'none. This is even the default for rbd driver (in the existing
> > command line interface, but I think we need to stay compatible with it).
> > With a union you would have to explicitly choose one or the other, but
> > could never accept both.
> > 
> > The other option we were considering was a list of authentication
> > options, which would be easier to implement, but isn't really an
> > accurate representation of what we really accept. There is no way we
> > could meaningfully implement something like this:
> > 
> >     'auth': [ { 'type': 'cephx', 'key-secret': 'foo' },
> >               { 'type': 'cephx', 'key-secret': 'bar' } ]
> > 
> > Because Ceph only allows us to enable the 'cephx' authentication method
> > and to set a single key for it.
> 
> How does it look as a choice between:
> 
> {'enum':'CephxAuth', 'data': ['none', 'cephx', 'both' ]}
> 
> where both 'cephx' and 'both' support the optional 'key-secret'
> parameter, but 'none' does not?

Doesn't really look extensible for the case that Ceph adds a third mode.
At least I don't think we want to have an enum and associated union
branches for all possible combinations?

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]