<div dir="ltr">How will that work with 3rd cinder party drivers?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 27, 2021 at 2:02 PM Daniel de Oliveira Pereira <<a href="mailto:Daniel.Pereira@windriver.com">Daniel.Pereira@windriver.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello everyone,<br>
<br>
We have prototyped some new features on Cinder for our clients, and we<br>
think that they are nice features and good candidates to be part of<br>
upstream Cinder, so we would like to get feedback from OpenStack<br>
community about these features and if you would be willing to accept<br>
them in upstream OpenStack.<br>
<br>
Our team implemented the following features for cinder-backup service:<br>
<br>
    1. A multi-backend backup driver, that allow OpenStack users to<br>
choose, via API/CLI/Horizon, which backup driver (Ceph or NFS, in our<br>
prototype) will be used during a backup operation to create a new volume<br>
backup.<br>
    2. An improved NFS backup driver, that allow OpenStack users to back<br>
up their volumes to private NFS servers, providing the NFS hostpath at<br>
runtime via API/CLI/Horizon, while creating the volume backup.<br>
<br>
Considering that cinder was configured to use the multi-backend backup<br>
driver, this is how it works:<br>
<br>
    During a volume backup operation, the user provides a "location"<br>
parameter to indicate which backend will be used, and the backup<br>
hostpath, if applicable (for NFS driver), to create the volume backup.<br>
For instance:<br>
<br>
    - Creating a backup using Ceph backend:<br>
    $ openstack volume backup create --name <backup_name> --location<br>
ceph <volume_id><br>
<br>
    - Creating a backup using the improved NFS backend:<br>
    $ openstack volume backup create --name <backup_name> --location<br>
nfs://my.nfs.server:/backups <volume_id><br>
<br>
    If the user chooses Ceph backend, the Ceph driver will be used to<br>
create the backup. If the user chooses the NFS backend, the improved NFS<br>
driver, previously mentioned, will be used to create the backup.<br>
<br>
    The backup location, if provided, is stored on Cinder database, and<br>
can be seen fetching the backup details:<br>
    $ openstack volume backup show <backup_name><br>
<br>
Briefly, this is how the features were implemented:<br>
<br>
    - Cinder API was updated to add an optional location parameter to<br>
"create backup" method. Horizon, and OpenStack and Cinder CLIs were<br>
updated accordingly, to handle the new parameter.<br>
    - Cinder backup controller was updated to handle the backup location<br>
parameter, and a validator for the parameter was implemented using the<br>
oslo config library.<br>
    - Cinder backup object model was updated to add a nullable location<br>
property, so that the backup location could be stored on cinder database.<br>
    - a new backup driver base class, that extends BackupDriver and<br>
accepts a backup context object, was implemented to handle the backup<br>
configuration provided at runtime by the user. This new backup base<br>
class requires that the concrete drivers implement a method to validate<br>
the backup context (similar to BackupDriver.check_for_setup_error)<br>
    - the 2 new backup drivers, previously mentioned, were implemented<br>
using these new backup base class.<br>
    - in BackupManager class, the "service" attribute, that on upstream<br>
OpenStack holds the backup driver class name, was re-implemented as a<br>
factory function that accepts a backup context object and return an<br>
instance of a backup driver, according to the backup driver configured<br>
on cinder.conf file and the backup context provided at runtime by the user.<br>
    - All the backup operations continue working as usual.<br>
<br>
Could you please let us know your thoughts about these features and if<br>
you would be open to adding them to upstream Cinder? If yes, we would be<br>
willing to submit the specs and work on the upstream implementation, if<br>
they are approved.<br>
<br>
Regards,<br>
Daniel Pereira<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arkady Kanevsky, Ph.D.<div>Phone: 972 707-6456</div><div>Corporate Phone: 919 729-5744 ext. 8176456<br><div></div></div></div></div>