Restore Resource Status
https://blueprints.launchpad.net/karbor/+spec/restore-resource-status
Protection plugin should be able to set the status of a restoring resource
during a restore operation. By doing so, users gain visiblity of the restore
process:
- Resources currently being protected
- Resources restored successfully
- Resources whose restore has failed, and the reason for the failure
Problem description
Use Cases
- Giving visibility for the restore process
- Exposing the user to the reason for the failure of a resource restore
Proposed Change
- Add ‘resource_status’ and ‘resource_reason’ dictionaries to the Restore object
- Add ‘update_resource_status’ method to the Restore object
- Protection Plugin should use the ‘update_resource_status’ to set the status of
each resource during restore operation
Alternatives
By not adding this, users will have no visibility to resource status during and
after restore operation.
Data model impact
- Add ‘resource_status’ dictionary to Restore object: represents the status of
the restoring/restored resource
- Add ‘resource_reason’ dictionary to Restore object: free text representing the
reason for the restore failure of the resource
REST API impact
- ‘resource_status’ dictionary and ‘resource_reason’ dictionary are added to the
Restore object
Security impact
Validation should be imposed on the status set by plugins, and on the reason
text.
Other end user impact
python-karborclient and karbor-dashboard should consume the new fields of the
Restore object.
Other deployer impact
Protection plugins should use the new API to set the resource status.
Implementation
Testing
Documentation Impact
- Add ‘resource_status’ and ‘resource_reason’ to Restore object
- Add ‘update_restore_status’ to Protection Plugin writing documentation