Glance requires read permissions on RBD volumes pool to check for children

[Simon Hensel]

When Glance tries to delete an image from the RBD/Ceph backend, it checks if any children exist for that image (see https://opendev.org/openstack/glance_store/src/branch/master/glance_store/_drivers/rbd.py#L459).

However, if we create a volume from an image, the children are part of the 'volumes' pool.
If we follow the Glance setup guide, we only grant permissions for the 'images' pool, but not for the 'volumes' pool (see https://docs.openstack.org/glance/latest/configuration/configuring.html#configuring-the-rbd-storage-backend).
This causes image deletion to fail with an internal server error due to missing permissions:
rbd.PermissionError: [errno 1] RBD permission error (error listing children.).

To circumvent this issue, the glance client requires read access on the 'volumes' pool. There may also be more finely tuned permissions, that allow glance to check for existing children, that I am not aware of.
Either way, the documentation should reflect this.

[Christian Rohmann (christian-rohmann)]

There also is documentation at Ceph on how to configure the required users and their permissions for OpenStack Glance and Cinder -
https://docs.ceph.com/en/latest/rbd/rbd-openstack/#setup-ceph-client-authentication

They also promote to use their managed capabilities called "profiles" such as "rbd" or "rbd-readonly" instead of raw ACLs such das "rwx". See https://docs.ceph.com/en/latest/rados/operations/user-management/#authorization-capabilities. This also differs in the Cinder / Glance documentation.

This makes are great difference as "such privileges include the ability to blocklist other client users." required for lock of stale RBD clients to be removed from images, see https://docs.ceph.com/en/latest/rbd/rbd-exclusive-locks/#rbd-exclusive-locks.

It would be awesome if the documentation could be aligned and have the most sensible defaults.

[Christian Rohmann (christian-rohmann)]

I posted about this issue to the ML: https://<email address hidden>/thread/E3VYY24HUGBNH7626ALOGZMJRVX5VOSZ/

Seems like this is a valid observation and needs at least some fixing in the documentation or even devstack.