Curator: Support latest snapshot restoration

[pickypg]

The support for snapshotting is phenomenal to the point where it's incredibly easy to automate. It would be great if we could take advantage of this on a secondary cluster to perform automatic restoration. Something along the lines of:

$ curator restore --repository REPO_NAME snapshot --latest-snapshot

Under the hood, this should be able to simply grab the existing snapshots from that repository and find the newest one. The nicest part is that, as long as you end up with a single snapshot at the end, the --latest-snapshot option on the snapshot subcommand could simply be an augmentation rather than a requirement (e.g., it gives the latest of all returned options, so you could combine it with the other options, even including --newer-than and --older-than).

[apatrida]

+1 ... seems odd curator cannot restore. If you write your own restore elsewhere, you have to either use the API from Python (for selection) and add the simple snapshot restore command, or need to reproduce all the behaviour of index selection somewhere else + restore.

[apatrida]

(or is there a philosophical reason snapshot restore is absent?)

[untergeek]

I haven't taken the time to add it because restore is a much less common use-case (or at least, it was) than backup is. I have an issue now requesting it, so it's on my plate now :smile:

[apatrida]

Our work flow moves data to processing nodes using backup and restore so it is part of the automated process a few times per day or more.

[robin13]

+1 with same workflow as @jaysonminard

[gmoskovicz]

+1 for this, while a restore should not be automated, it is great to have a simple command to restore a snapshot using curator.

[untergeek]

This feature has been delayed. It has way more parts to test than it first appears. I have a work-in-progress branch, but it will not make 3.3.0.

[PhaedrusTheGreek]

+1 - this will be handy to automate DR cluster sync

[Jmusa]

+1, for DR.

[untergeek]

I'm finally adding this, everyone.