Restore dry run option

[rocketraman]

A dry-run option to ark restore create would be awesome. Given that we don't have any easy visibility as to what's inside a backup (as per issue #396), doing a partial ark restore is a bit of a hair-raising / fingers crossed event, because the right values we need to pass to --include-resources and --exclude-resources are not at all obvious.

A dry-run option would list the actions ark would take / print the restore log given the parameters passed but not actually carry out those actions.

[rosskukulinski]

Yes! I think this is a critical user experience feature enhancement. This should probably be in-place before we go to implement #469.

[rosskukulinski]

I'd like to propose having a backup AND restore --dry-run that will capture what resources are to be captured/snapshotted. Having the backup dry-run would help in situations like #579 where the user isn't sure what will be backed up.

[ncdc]

We need to figure out the technical means to achieve this. Ark is not an aggregated API server, so we don't have the ability for the ark client to send an http request to the Ark pod and wait for a response. What we've done so far for "request-response" semantics is to have the ark client create a custom resource and wait for it to be updated with the response information.

There is a challenge to that: etcd has a 1.5MB entry size limit, so we can't stuff the response into a single custom resource because we might exceed the limit.

We could upload the response to object storage, then give the client a pre-signed URL it can use to download the response (this is what we do for ark backup download, ark backup logs, and ark restore logs).

We could create a series of small custom resources (like Kubernetes events). I worry, though, that that might overwhelm the apiserver at some point.

[ncdc]

Including info from 654: make sure we allow plugins to know if this is a dry-run or real.

[jprecuch]

@ncdc is there something for this ongoing or was this put on hold for now?

[ncdc]

Hi @jprecuch, I don't work on Velero any more, but @carlisia @nrb @ashish-amarnath should be able to help you

[xeor]

Still no way to know what you are about to restore before you restore..?

[BalintSzigeti]

yep, that feature would be welcomed..... :/

[mackmittal-wk]

any updates on this feature request ?

[mattiasnensen]

This feature is very much wanted by me as well.

[kaovilai]

I can be assigned this issue

[sseago]

I think restore is more critical than backup, since on the backup side, just doing a backup with snapshotVolumes=false will get you the same thing as long as the object list isn't huge (if obj list is huge you don't want the tarball).

Rough idea of how I think this should work:

• for restore:
  • add new spec.DryRun field
  • if dry run, skip create/patch calls on resource
  • if dry run, skip PVR/DataDownload creation
  • plugins should be encouraged to check restore.spec.dryRun before directly creating anything in-cluster (normal modifying yaml/returning additional items, and passing withoutRestore should happen as usual, since that affects what resources would have been restored) .
  • upload log, results, and restore resource list as usual
• for backup:
  • add new spec.DryRun field
• if dry run, don't create/upload resource tarball
  • if dry run, skip PVR/DataDownload creation
  • plugins should be encouraged to check backup.spec.dryRun before directly creating anything in-cluster (normal modifying yaml/returning additional items should happen as usual, since that affects what resources would have been backed up) .
  • upload log, results, and bakcup resource list as usual