Difference between revisions of "Cross-region-backup-availability"
(→Justification/Benefits) |
(→Configuration) |
||
Line 8: | Line 8: | ||
==Impacts== | ==Impacts== | ||
===Configuration=== | ===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/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
Contents
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?