Hello everyone,

We have prototyped some new features on Cinder for our clients, and we
think that they are nice features and good candidates to be part of
upstream Cinder, so we would like to get feedback from OpenStack
community about these features and if you would be willing to accept
them in upstream OpenStack.

Our team implemented the following features for cinder-backup service:

    1. A multi-backend backup driver, that allow OpenStack users to
choose, via API/CLI/Horizon, which backup driver (Ceph or NFS, in our
prototype) will be used during a backup operation to create a new volume
backup.
    2. An improved NFS backup driver, that allow OpenStack users to back
up their volumes to private NFS servers, providing the NFS hostpath at
runtime via API/CLI/Horizon, while creating the volume backup.

Considering that cinder was configured to use the multi-backend backup
driver, this is how it works:

    During a volume backup operation, the user provides a "location"
parameter to indicate which backend will be used, and the backup
hostpath, if applicable (for NFS driver), to create the volume backup.
For instance:

    - Creating a backup using Ceph backend:
    $ openstack volume backup create --name <backup_name> --location
ceph <volume_id>

    - Creating a backup using the improved NFS backend:
    $ openstack volume backup create --name <backup_name> --location
nfs://my.nfs.server:/backups <volume_id>

    If the user chooses Ceph backend, the Ceph driver will be used to
create the backup. If the user chooses the NFS backend, the improved NFS
driver, previously mentioned, will be used to create the backup.

    The backup location, if provided, is stored on Cinder database, and
can be seen fetching the backup details:
    $ openstack volume backup show <backup_name>

Briefly, this is how the features were implemented:

    - Cinder API was updated to add an optional location parameter to
"create backup" method. Horizon, and OpenStack and Cinder CLIs were
updated accordingly, to handle the new parameter.
    - Cinder backup controller was updated to handle the backup location
parameter, and a validator for the parameter was implemented using the
oslo config library.
    - Cinder backup object model was updated to add a nullable location
property, so that the backup location could be stored on cinder database.
    - a new backup driver base class, that extends BackupDriver and
accepts a backup context object, was implemented to handle the backup
configuration provided at runtime by the user. This new backup base
class requires that the concrete drivers implement a method to validate
the backup context (similar to BackupDriver.check_for_setup_error)
    - the 2 new backup drivers, previously mentioned, were implemented
using these new backup base class.
    - in BackupManager class, the "service" attribute, that on upstream
OpenStack holds the backup driver class name, was re-implemented as a
factory function that accepts a backup context object and return an
instance of a backup driver, according to the backup driver configured
on cinder.conf file and the backup context provided at runtime by the user.
    - All the backup operations continue working as usual.

Could you please let us know your thoughts about these features and if
you would be open to adding them to upstream Cinder? If yes, we would be
willing to submit the specs and work on the upstream implementation, if
they are approved.

Regards,
Daniel Pereira