How will that work with 3rd cinder party drivers?
On Fri, Aug 27, 2021 at 2:02 PM Daniel de Oliveira Pereira < Daniel.Pereira@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 tochoose, 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> --locationceph <volume_id>
- Creating a backup using the improved NFS backend: $ openstack volume backup create --name <backup_name> --locationnfs://my.nfs.server:/backups <volume_id>
If the user chooses Ceph backend, the Ceph driver will be used tocreate 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, andcan 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