On Mon, Jun 16, 2025 at 11:25:54AM +0200, Ilya Dryomov wrote: > On Thu, May 15, 2025 at 1:29 PM Fiona Ebner <f.eb...@proxmox.com> wrote: > > > > Currently, most Ceph configuration options are not exposed via QAPI. > > While it is possible to specify a dedicated Ceph configuration file, > > specialized options are often only required for a selection of images > > on the RBD storage, not all of them. To avoid the need to generate a > > dedicated Ceph configuration file for each image (or for each required > > combination of options), support a selection of key-value pairs via > > QAPI. > > > > Initially, this is just 'rbd_cache_policy'. For example, this is > > useful with small images used as a pflash for EFI variables. Setting > > the 'rbd_cache_policy' to 'writeback' yields a substantial improvement > > there [0]. > > > > The function qemu_rbd_extract_key_value_pairs() was copied/adapted > > from the existing qemu_rbd_extract_encryption_create_options(). > > > > [0]: https://bugzilla.proxmox.com/show_bug.cgi?id=3329#c9 > > > > Signed-off-by: Fiona Ebner <f.eb...@proxmox.com>
snip > > ## > > # @BlockdevOptionsRbd: > > # > > @@ -4327,6 +4360,9 @@ > > # authentication. This maps to Ceph configuration option "key". > > # (Since 3.0) > > # > > +# @key-value-pairs: Key-value pairs for additional Ceph configuraton. > > +# (Since 10.1) > > +# > > # @server: Monitor host address and port. This maps to the "mon_host" > > # Ceph option. > > # > > @@ -4342,6 +4378,7 @@ > > '*user': 'str', > > '*auth-client-required': ['RbdAuthMode'], > > '*key-secret': 'str', > > + '*key-value-pairs' : 'RbdKeyValuePairs', > > To side-step all of the above, have you considered implementing > a straightforward passthrough to Ceph instead? Something like > > '*key-value-pairs': ['RbdKeyValuePair'] > > where RbdKeyValuePair is just a pair arbitrary strings (and > key-value-pairs is thus an optional list of those). rados_conf_set() > would be called just the same but the user would be able to override > any Ceph option they wish, not just a few that we thought of here. Passing through arbitrary key/value pairs as strings is essentially abdicating our design responsibility in QAPI. enums would no longer be introspectable. Integers / booleans would require abnormal formatting by clients. API stability / deprecation promises can no longer be made. and more besides. Given that limitation, if we did go the string pairs route, I would expect it to be marked as "unstable" in the QAPI schema, so apps have a suitable warning NOT to rely on this. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
