c61c1977c2
In order to ensure that a share existed, we used to send the same request to Ceph as we would do with the share creation. In that request, we will set the share mode, which is a value set by the deployer through the `cephfs_volume_mode` config option. If the share was already created, Ceph would not override the value we were forwarding for the permission mode. After a bugfix [1], the value of mode started being reinforced when sent, even if the subvolume was already created. If the value for `cephfs_volume_mode` changed after the share was created, the mode is now being overwritten after manila startup on ensure_shares. Fixed this issue by modifying the ensure_shares to only confirm if the export exists. [1] https://tracker.ceph.com/issues/54375 Closes-Bug: #2002394 Change-Id: Ic5b5b42b882ce1346b4b46d1b29aa31740933e0e
14 lines
781 B
YAML
14 lines
781 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Fixed an issue that made the CephFS driver to override the permissions in
|
|
a share. After `a bugfix <https://tracker.ceph.com/issues/54375>`_, Ceph's
|
|
idempotent creation of shares had a change on its behavior. If a share
|
|
mode was modified outside of Manila, or the configuration value for
|
|
`cephfs_volume_mode` was changed in Manila when shares had already been
|
|
created, these shares would have their mode changed while Manila attempted
|
|
to ensure that such share exists using the idempotent creation, potentially
|
|
breaking clients. The CephFS driver will no longer send create calls to the
|
|
backend when ensuring a share exists. For more details, please refer to
|
|
`Bug #2002394 <https://bugs.launchpad.net/manila/+bug/2002394>`_
|