Open Stack

How will that work with 3rd cinder party drivers?

On Fri, Aug 27, 2021 at 2:02 PM Daniel de Oliveira Pereira <
Daniel.Pereira at windriver.com> wrote:

> 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
>
>

-- 
Arkady Kanevsky, Ph.D.
Phone: 972 707-6456
Corporate Phone: 919 729-5744 ext. 8176456
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210827/093f7775/attachment-0001.html>