Difference between revisions of "Trove/backup-metadata"

Latest revision as of 06:05, 24 April 2014

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) 06:05, 24 April 2014 (UTC): makes complete sense, thanks for the explanation.
• 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.