Perfrom validation by the backup strategy on restore call
Description:
Perfrom validation by the backup strategy on restore call
Justification/
- backp from mysql could be used for restoring mongo instance;
- Does it allow for great flexibility? Stability? Security? - Yes, additional validation is required.
Impacts:
Configuration:
- no additional options (yet).
Public API:
-
Internal API:
-
Guest Agent:
-
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Denis M.
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Approved
- Series goal:
- Accepted for icehouse
- Implementation:
-
Implemented
- Milestone target:
-
ongoing
- Started by
- Nikhil Manchanda
- Completed by
- Nikhil Manchanda
Related branches
Related bugs
Sprints
Whiteboard
(SlickNik) This bp was discussed in #openstack-trove on 2014/03/10. During the discussion, the following points were noted:
- We don't need to restrict restores to only working on an instance with same datastore type / version.
- Strategies for backup / restore can exist that can work across datastores (eg. innobackupex on mysql / percona).
- We may need a one-to-many map of which strategies are valid for which datastores / versions.
The above concerns need to be addressed before the bp can be re-considered for approval.
(amcrn) 03/12: After talking about this internally, tying it to the manager is not restrictive enough. The reason being is this means a percona backup can be applied to a mysql backup, and if someone else has say MySQL 5.6, or 5.1, or <something else> utilizing the same manager, then the same issue applies. long-term, the backup table needs to have much more metadata recorded, namely: the backup tool's version, the datastore-version id, the datastore-version manager (because the manager for a version can be changed, and you'd have no idea), and possibly more. to prevent use-cases from forming that rely on the current broken validation, the patch-set landing in icehouse should be extremely restrictive: datastore-
(mat-lowery) 03/13: Just adding my thoughts from the aforementioned internal discussion. The long term solution may be a combination of failing fast (reject at the API layer) but delegating the decision (synchronous call to guest agent) so that the guest agent, along with the extended metadata mentioned by amcrn, can make the most informed decision about whether it can restore successfully (since it will be doing the actual restore). Anything else may prevent a restore that could succeed or allow a restore that has no chance of succeeding.
