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.
Yes! I think this is a critical user experience feature enhancement. This should probably be in-place before we go to implement #469.
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.
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.
Including info from 654: make sure we allow plugins to know if this is a dry-run or real.
@ncdc is there something for this ongoing or was this put on hold for now?
Hi @jprecuch, I don't work on Velero any more, but @carlisia @nrb @ashish-amarnath should be able to help you
Most helpful comment
I'd like to propose having a backup AND restore
--dry-runthat 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.