Re-sending this because the PTL somehow missed this agenda item for today's Cinder meeting (which just ended). We'll discuss this at next week's cinder virtual R-9 mid-cycle (wednesday 10 Feb 1400-1600 UTC): https://etherpad.opendev.org/p/cinder-wallaby-mid-cycles On 1/29/21 12:29 PM, Gorka Eguileor wrote:
Hi all,
In the next Cinder meeting I'll bring a Backup driver issue up for discussion, and this email hopefully provides the necessary context to have a fruitful discussion.
The issue is around the `container` optional parameter in backup creation, and its user and administrator unfriendliness.
The interpretation of the `container` parameter is driver dependent, and it's being treated as:
- A bucket in Google Cloud Storage and the new S3 driver - A container in Swift - A pool in Ceph - A directory in NFS and Posix
Currently the only way to prevent cloud users from selecting a different `container` is by restricting what the storage user configured in Cinder backup can do.
For Ceph we can make the storage user unable to access any other existing pools, for Swift, GCS, and S3 we can remove permissions to create buckets/containers from the storage user.
This achieves the administrator's objective of not allowing them to change the `container`, but cloud users will have a bad experience, because the API will accept the request but the backup will go into `error` state and they won't see any additional information.
And this solution is an all or nothing approach, as we cannot allow just some cloud users select the container while preventing others from doing so. For example we may want some cloud users to be able to do backups on a specific RBD pool that is replicated to a remote location.
I think we can solve all these issues if we:
- Create a policy for accepting the `container` parameter on the API (defaulting to allow for backward compatibility).
- Add a new configuration option `backup_container_regex` to control acceptable values for the `container` (defaults to `.*` for backward compatibility).
This option would be used by the backup manager (not the drivers themselves) on backup creation, and would result in a user message if the provided container was not empty and failed the regex check.
I think this summarizes the situation and my view on the matter.
Feedback is welcome here or in the next Cinder meeting.
Cheers, Gorka.