cinder-specs/specs/victoria/backup-backends-configuration.rst
Ivan Kolodyazhny 8ffad2aec7 Backup Backends Configuration
Change-Id: Ifa4c6c0ab8ef79d889a092f3caaf7304316cb3d5
Related: blueprint backup-backends-configuration
2020-07-01 12:56:22 +03:00

218 lines
5.5 KiB
ReStructuredText

..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
===================================
Backup Multi-Backends Configuration
===================================
https://blueprints.launchpad.net/cinder/+spec/backup-backends-configuration
Add a new config section for backup configuration options to unify the way how
we do it with volume drivers and support multiple backup drivers in one
service.
Problem description
===================
Right now we've got all backup-specific configuration options defined in the
[DEFAULT] section::
[DEFAULT]
backup_driver = cinder.backup.drivers.ceph.CephBackupDriver
backup_ceph_user = cinder-backups
backup_ceph_pool = volume-backups
...
It leads to mix of backup-specific config options and Cinder general
configuration. This approach also doesn't support backups multi-backend.
Operators can configure multiple backup backends only by configuring several
cinder-backup services.
Current approach blocks Generic backup implementation because drivers
self.configuration won't be able to see required configuration which are
defined in the [DEFAULT] section.
Use Cases
=========
The main use-case here is to decouple backup-specific configuration from the
[DEFAULT] section and introduce a backup_type.
Proposed change
===============
The new config option called 'enabled_backup_backends' will contain a
list of enabled backup backends. This will implement the same approach as we
have for volumes with 'enabled_backends' config option.
All backup-related configuration will be moved into the new backend-specific
section::
[DEFAULT]
enabled_backup_backends = ceph_backup, ceph_backup_ssd
default_backup_type = ceph-backup-type
...
[ceph_backup]
backup_driver = cinder.backup.drivers.ceph.CephBackupDriver
backup_ceph_user = cinder-backups
backup_ceph_pool = volume-backups
[ceph_backup_ssd]
backup_driver = cinder.backup.drivers.ceph.CephBackupDriver
backup_ceph_user = cinder-backups
backup_ceph_pool = volume-backups-ssd
The old-style backup configuration will be supported at least for one release
to follow all deprecation policies.
With multi-backups configuration we want to introduce backup types too. It
will help us to use all multi-backend advantages. Backup types will follow the
same approach as volume types have:
* __DEFAULT__ backup type will be introduced and all existing backups will be
migrated to this backup type.
* `default_backup_type` config option will be introduced.
* Backup types will have own extra specs.
Alternatives
------------
Leave everything as-is and introduce some hacks in the code to get volume
drivers working as a backup drivers in the scope of Generic Backup feature.
Data model impact
-----------------
New tables for backup types will be introduced. We'll follow the same approach
as for volume types which works well for Cinder:
BackupType
+--------------+--------------+
| Field | Type |
+--------------+--------------+
| created_at | datetime |
| updated_at | datetime |
| id | varchar(36) |
| name | varchar(255) |
| description | varchar(255) |
| deleted | boolean |
| is_public | boolean |
+--------------+--------------+
BackupTypeProjects
+----------------+--------------+
| Field | Type |
+----------------+--------------+
| created_at | datetime |
| updated_at | datetime |
| id | varchar(36) |
| project_id | varchar(36) |
| backup_type_id | varchar(36) |
| deleted | boolean |
+----------------+--------------+
BackupTypeExtraSpecs
+----------------+--------------+
| Field | Type |
+----------------+--------------+
| created_at | datetime |
| updated_at | datetime |
| key | varchar(255) |
| value | varchar(255) |
| deleted | boolean |
+----------------+--------------+
REST API impact
---------------
New API endpoints will be implemented for backup types. It should be similar
like volume type API.
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
Backup creation procedure will contain few more database calls but it should
not affect performance a lot.
Other deployer impact
---------------------
Operators should configure backups using a new mechanism and migrate from
old-style configuration.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
e0ne
Work Items
----------
* Add a new 'enabled_backup_backends' config option and deprecate old-style
config
* Modify the backup manager to honor new configuration
* Add some unit tests
* Devstack should be able to configure cinder backups in a new way
* Operator documentation should be updated
* API reference should be updated
Dependencies
============
None
Testing
=======
* Unit tests
* Existing tempest tests will cover new functionality
Documentation Impact
====================
* Update documentation to describe new config option
* New REST API endpoints will be documented
References
==========
* https://blueprints.launchpad.net/cinder/+spec/backup-backends-configuration
* https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/scalable-backup-service.html
* https://specs.openstack.org/openstack/cinder-specs/specs/train/untyped-volumes-to-default-volume-type.html