On 03/23/2017 04:43 PM, Eric Blake wrote: > We'd still have to allow libvirt's use of > ":key=...:auth_supported=cephx\\;none" on the command line, but from the > QMP side, we would support exactly one auth method, and libvirt will be > updated to match when it starts targetting blockdev-add instead of > legacy command line. > > If librados really needs 'cephx;none' any time cephx authorization is > requested, then even though the QMP only requests 'cephx', we can still > map it to 'cephx;none' in qemu - but I'm hoping that setting > auth_supported=cephx rather than auth_supported=cephx;none on the > librados side gives us what we (and libvirt) really want in the first place.
Or, if it becomes something that libvirt wants to allow users to tune in their XML (right now, users don't get a choice, they get either 'none' or 'cephx;none'), a forward-compatible solution under my QMP proposal would be to have qemu add a third enum state, "none", "cephx", and "cephx-no-fallback". On the other hand, if supporting multiple methods at once makes sense (say librados adds a 'cephy' method, and that users could legitimately use both 'cephx;cephy' and 'cephy;cephx' with different behaviors), then keeping auth as an array of instances of a simple flat union scales nicer than having to add a combinatorial explosion of branches to the flat union to cover every useful combination of auth_supported methods. Maybe I'm overthinking it. > > Jeff or Josh, if you could chime in, that would be helpful. > -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
