Backup drivers issue with the container parameter

Gorka Eguileor geguileo at
Fri Jan 29 17:29:23 UTC 2021

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

  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.


More information about the openstack-discuss mailing list