Trove/backup-metadata
< Trove
Contents
Description
This blueprint will add the datastore and version to the backups api response.
Blueprint: https://blueprints.launchpad.net/trove/+spec/backup-metadata
Justification/Benefits
- This will allow filtering the backups list by datastore type (and version?)
- Eventually allow the api to restrict which datastore a backup could be restored to. (mysql -> mysql) (redis -> redis)
Impacts
Configuration
None
Database
- The backup table will need to have a foreign key to the Datastore Version table.
- This will require a migration to add the foreign key to all existing records
Public API
- This will add the datastore type and version to the API Response
- This will also add the ability to filter the backup list by datastore
CLI interface
- This will add a single param to backup-list command '--datastore' to filter the list by that datastore
ReST Part
New backup list Response:
HTTP/1.1 200 OK Content-Type: application/json Via: 1.1 Repose (Repose/2.6.7) Content-Length: 663 Date: Thu, 13 Feb 2014 21:47:16 GMT Server: Jetty(8.0.y.z-SNAPSHOT) { "backups": [ { "created": "2014-02-13T21:47:16", "datastore": { "type": "mysql", "version": "5.5" } "description": "My Backup", "id": "014cfa93-fd0e-4e9d-871f-da8bb2eeee3e", "instance_id": "dcf2c32b-241d-4c39-af70-1001dfe946d6", "locationRef": "http://localhost/path/to/backup", "name": "snapshot", "parent_id": null, "size": null, "status": "COMPLETED", "updated": "2014-02-13T21:47:16" } ] }
New Backup GET by ID
HTTP/1.1 200 OK Content-Type: application/json Via: 1.1 Repose (Repose/2.6.7) Content-Length: 335 Date: Thu, 13 Feb 2014 21:47:16 GMT Server: Jetty(8.0.y.z-SNAPSHOT) { "backup": { "created": "2014-02-13T21:47:16", "datastore": { "type": "mysql", "version": "5.5" } "description": "My Backup", "id": "61f12fef-edb1-4561-8122-e7c00ef26a82", "instance_id": "d4603f69-ec7e-4e9b-803f-600b9205576f", "locationRef": "http://localhost/path/to/backup", "name": "snapshot", "parent_id": null, "size": null, "status": "COMPLETED", "updated": "2014-02-13T21:47:16" } }
Internal API
- No change in the internal api, only to the initial model creation code in the backup models.
RPC API description
- No change
Guest Agent
- No Change
Comments/Questions From Community
- amcrn (talk) 17:21, 15 April 2014 (UTC): datastore-type and datastore-version information should be returned for backup-instance-list in addition to backup-list and backup-show.
- amcrn (talk) 17:21, 15 April 2014 (UTC): given in the near future an instance can be upgraded via the api from datastore-version 'x' to datastore-version 'y', it makes sense that the datastore-type and datastore-version are returned in backup-list-instance, as well as backup-show and backup-list. what's not immediately clear to me is why someone would want to filter a backup-list by datastore or datastore-version? can you provide a use-case?
- --Daniel Morris (talk) 20:20, 23 April 2014 (UTC)Think about the case of a UI and optimizing the UX experience when there are multiple datastores and types. If I am a MySQL instance vs. a Redis instance. When I am in the context of Redis, I want to only see the backps for Redis, and when i am working with MySQL, I only want to see the backups for MySQL. The same applies for Restores. It allows you to filter and or create facet's based on the datastore / version context you are working under. (E.g. preventing users from inadvertently attempting to restore a MySQL backup to a Redis instance.)
- amcrn (talk) 17:21, 15 April 2014 (UTC): as it stands today, a datastore-version is tied to a manager, and a manager has an optgroup. in the near future, backup_strategy and restore_strategy will be moved from the DEFAULT optgroup to a manager-specific optgroup (see https://review.openstack.org/#/c/77899/11/etc/trove/trove-guestagent.conf.sample). this indirectly means that a manager has an associated backup/restore_strategy. since the cloud provider has the ability to change the backup/restore_strategy at any time, the manager name isn't enough information to know whether the backup can be restored to a specific datastore-version. therefore, the backup and restore strategies must be stored in the backup table. the datastore-version should also be stored because a datastore might use the exact same commands (aka same manager impl) to create a backup for version 'x' as compared to version 'y', but the output for 'x' might be incompatible for import into 'y' (maybe the underlying data arrangement/packing changed, etc.). Without being an expert in all datastore's backup limitations across major and minor versions, it's difficult to guess whether the backup/restore_strategy code changes often. one thing is certain however, recording more information is always better than not having enough. note: for now, backup/restore_strategy in this scenario would not be returned in show/list calls.