import requests
url = "https://platform.ankra.app/org/applications/{application_id}/deployments/{deployment_id}/restore-points/{restore_point_id}/restore-plan"
headers = {"cookie": "ankra_session="}
response = requests.get(url, headers=headers)
print(response.text)const options = {method: 'GET', headers: {cookie: 'ankra_session='}};
fetch('https://platform.ankra.app/org/applications/{application_id}/deployments/{deployment_id}/restore-points/{restore_point_id}/restore-plan', options)
.then(res => res.json())
.then(res => console.log(res))
.catch(err => console.error(err));curl --request GET \
--url https://platform.ankra.app/org/applications/{application_id}/deployments/{deployment_id}/restore-points/{restore_point_id}/restore-plan \
--cookie ankra_session={
"restore_point_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"stack_name": "<string>",
"cluster_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"cluster_name": "<string>",
"mode": "in_place",
"force": true,
"effects_known": true,
"steps": [
"<string>"
],
"replaces": [
{
"namespace": "<string>",
"claim": "<string>"
}
],
"restores_namespace_objects": [
"<string>"
],
"safety_copy": "will_take",
"refusals": [
{
"code": "mode_unsupported",
"message": "<string>",
"force_overrides": true
}
],
"drift": true,
"drift_known": true,
"drift_details": [
"<string>"
],
"not_carried": [
{
"kind": "<string>",
"name": "<string>",
"reason": "<string>",
"remedy": "<string>"
}
],
"warnings": [
"<string>"
]
}Preview restoring an application deployment (browser session)
Answers what restoring this deployment in place from this restore point would do if it were confirmed now, without doing any of it: the steps in order with the volume claims they remove, the namespaces whose objects are restored, whether a safety copy of the live stack is taken first, every reason the restore would be refused, and whether the stack has drifted. It opens no run, mints no restore point and writes nothing to the stack. The stack is resolved from the application’s own records; a restore point captured from another stack or cluster is not found here. Requires the backups rollout flag and backups.read.
import requests
url = "https://platform.ankra.app/org/applications/{application_id}/deployments/{deployment_id}/restore-points/{restore_point_id}/restore-plan"
headers = {"cookie": "ankra_session="}
response = requests.get(url, headers=headers)
print(response.text)const options = {method: 'GET', headers: {cookie: 'ankra_session='}};
fetch('https://platform.ankra.app/org/applications/{application_id}/deployments/{deployment_id}/restore-points/{restore_point_id}/restore-plan', options)
.then(res => res.json())
.then(res => console.log(res))
.catch(err => console.error(err));curl --request GET \
--url https://platform.ankra.app/org/applications/{application_id}/deployments/{deployment_id}/restore-points/{restore_point_id}/restore-plan \
--cookie ankra_session={
"restore_point_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"stack_name": "<string>",
"cluster_id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
"cluster_name": "<string>",
"mode": "in_place",
"force": true,
"effects_known": true,
"steps": [
"<string>"
],
"replaces": [
{
"namespace": "<string>",
"claim": "<string>"
}
],
"restores_namespace_objects": [
"<string>"
],
"safety_copy": "will_take",
"refusals": [
{
"code": "mode_unsupported",
"message": "<string>",
"force_overrides": true
}
],
"drift": true,
"drift_known": true,
"drift_details": [
"<string>"
],
"not_carried": [
{
"kind": "<string>",
"name": "<string>",
"reason": "<string>",
"remedy": "<string>"
}
],
"warnings": [
"<string>"
]
}Authorizations
Browser session. Mutations also require X-Ankra-CSRF.
Path Parameters
The deployment cluster id.
Query Parameters
Plan the forced restore: drift is then reported and no longer refused.
Response
The plan. A plan with refusals is still a 200: the refusals are its content.
What restoring one application deployment in place from one restore point would do if it were confirmed now. Nothing in it has happened. It is produced by the same assessment the restore runs, so a refusal listed here is the refusal the restore answers with. Three fields say whether the others were established: when effects_known is false, steps, replaces and restores_namespace_objects are empty because the plan stopped before the restore point could be read, not because the restore touches nothing; when drift_known is false, drift was not compared; and safety_copy unknown means the copy was not planned.
The stack this deployment runs as, resolved on the server. It is the value the restore's confirm must match.
in_place Whether this is the plan of a forced restore.
The sequence the restore performs, in order, naming the claims it removes. The restore's 202 repeats these lines as sequence.
Every volume claim the restore deletes before it writes the copy back.
Show child attributes
Show child attributes
Namespaces whose Kubernetes objects the restore puts back as well: the volume engine restores a whole namespace, not only the claims named.
will_take: the live stack is captured first and the restore is refused if that capture cannot be taken. nothing_to_keep: the live stack holds nothing a capture can carry and the restore removes nothing. unavailable: the live stack cannot be captured, so the restore is refused. unknown: the plan stopped before the copy could be planned.
will_take, nothing_to_keep, unavailable, unknown Why a restore confirmed now would be refused, in the order the restore meets them; the first is the one the restore answers with. Empty means it would be accepted.
Show child attributes
Show child attributes
What the restore point does not contain, and so what the restore will not bring back.
Show child attributes
Show child attributes