Jump to: navigation, search

Difference between revisions of "Cross-region-backup-availability"

(Justification/Benefits)
(Configuration)
Line 8: Line 8:
 
==Impacts==
 
==Impacts==
 
===Configuration===
 
===Configuration===
Does this impact any configuration files? If so, which ones?
+
Most of the configs needed would be credential to access the storage in the different region. If we use swift as the storage strategy and swift is accessible globally and cross-region, we can reuse the same credentials to verify accessibility.
 +
 
 +
We can also provide a flag to enable this feature. Although this might not be required and could be handle in the new [[Trove/trove-capabilities|trove-capabilities]] feature.
 +
 
 
===Database===
 
===Database===
 
Does this impact any existing tables? If so, which ones?
 
Does this impact any existing tables? If so, which ones?

Revision as of 18:15, 1 April 2014

Description

This feature allows users to create a new backup from a different backup in a different region. The source backup must be stored in a globally accessible storage.

Justification/Benefits

By having this feature, the user can migrate backups from one region to another region. This will allow users to migrate their databases from one region to a different region by simply creating a backup, migrating it to another region and restoring it in that region.

Impacts

Configuration

Most of the configs needed would be credential to access the storage in the different region. If we use swift as the storage strategy and swift is accessible globally and cross-region, we can reuse the same credentials to verify accessibility.

We can also provide a flag to enable this feature. Although this might not be required and could be handle in the new trove-capabilities feature.

Database

Does this impact any existing tables? If so, which ones? Are the changes forward and backward compatible? Be sure to include the expected migration process

Public API

Does this change any API that an end-user has access to? Are there any exceptions in terms of consistency with other APIs?

CLI interface

How the command will look like? Does it extends the already existed command interfaces ?

ReST Part

Which HTTP methods added ? Which routes were added/modified/extended? How does the Request body look like? How does the Response object look like?

Internal API

Does this change any internal messages between API and Task Manager or Task Manager to Guest

RPC API description

Method name. Method parameters. Message type (cast/call).

Guest Agent

Does this change behavior on the Guest Agent? If so, is it backwards compatible with API and Task Manager?