Backup Multi-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.
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.
The main use-case here is to decouple backup-specific configuration from the [DEFAULT] section and introduce a backup_type.
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.
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.
Other end user 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.
- Primary assignee:
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
Existing tempest tests will cover new functionality
Update documentation to describe new config option
New REST API endpoints will be documented