Perfrom validation by the backup strategy on restore call

Registered by Denis M. on 2014-03-06

Description:
Perfrom validation by the backup strategy on restore call

Justification/Benefits:
- 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:
milestone icon ongoing
Started by
Nikhil Manchanda on 2014-04-16
Completed by
Nikhil Manchanda on 2014-04-16

Related branches

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-version-id has to match. shortly after icehouse is cut, we can land something that permits manager-to-manager restores. it's always easier to loosen restrictions than to tighten them after the fact, and considering that in the public repository no datastore has multiple versions yet, this shouldn't have any impact.

(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.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.