Open Stack

On 27/08, Daniel de Oliveira Pereira 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.

Hi Daniel,

Thank you very much for your willingness to give back!!!


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

This is a feature that has been discussed before, and e0ne already did
some of the prerequisites for it.


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

What about the username and password?
Can backups be restored from a remote location as well?

This sounds like a very cool feature, but I'm not too comfortable with
having it in Cinder.

The idea is that Cinder provides an abstraction and doesn't let users
know about implementation details.

With that feature as it is a user could request a backup to an off-site
location that could result in congestion in one of the outbound
connections.

I can only think of this being acceptable for admin users, and in that
case I think it would be best to use the multi-backup destination
feature instead.

After all, how many times do we have to backup to a different location?
Maybe I'm missing a use case.

If the community thinks this as a desired feature I would encourage
adding it with a policy that disables it by default.


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

When this feature was discussed upstream we liked the idea of
implementing this like we do multi-backends for the volume service,
adding backup-types.

In latest code backup creation operations have been modified to go
through the scheduler, so that's a piece that is already implemented.


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

I believe you will have the full community's support on the first idea
(though probably not on the proposed implementation).

I'm not so sure on the second one, iti will most likely depend on the
use cases.  Many times the reasons why features are dismissed upstream
is because there are no clear use cases that justify the addition of the
code.

Looking forward to continuing this conversation at the PTG, IRC, in a
spec, or through here.

Cheers,
Gorka.