Allow snapshot names to be rotated with most recent being named "_latest"

[PSjoe]

Describe the feature you'd like to have.
We are using a scheduler to create regular (hourly) snapshots of a source volume. We have a stateful set that needs to create a volume (using the "volumeClaimTemplate" option). It would be very helpful if we could have the most recent snapshot created be named '-latest' instead of the timestamp.

What is the value to the end user? (why is it a priority?)
When using snapshots as part of a StatefulSet VolumeClaimTemplate, Kubernetes fails if you try to update the DataSource part of the VolumeClaim template. Say, for example, to use a more recent snapshot. The workaround it a bit dangerous and error prone: Delete the StatefulSet with --cascade=false and then re-create it with the newer snapshot ID.

If we knew we could always expect our optimal snapshot to be suffixed with '-latest' (or something else obvious), we wouldn't need to change the datasource in the StatefulSet's VolumeClaimTemplate.

How will we know we have a good solution? (acceptance criteria)
When we can increase the replica count of a StatefulSet and have it always use the most recent snapshot as it's datasource for the PVC.

Additional context
Not sure if this is a bit of an edge case, but it would be super-useful for things like blockchains. Each node has a huge ledger volume. The closer to"now" that we can get when provisioning the volumes for additional pods, the faster the pods can be up and ready.

[PSjoe]

I just realized this isn't a trivial ask, since you cannot rename Kubernetes objects.

About the only way I could envision it working is if any given snapshot schedule invocation created two at the same time. One with the usual naming, and one with a name of '-latest'. Of course, each invocation would have to delete the existing '-latest' before proceeding.

[JohnStrunk]

For just the reason you mention (being able to easily reference the "latest"), I'd have much preferred a naming scheme like schedule-0, schedule-1, ... for each of the snaps that are retained (0 being the most recent). But, as you mentioned, renaming is not directly supported.

It would be possible to create a 2nd, "-latest" as you suggest, though I'm concerned about 2 things:

• Delete before create means that a failure could leave you with no "latest"
• Since it would be 2 snapshot operations (timestamp + latest), the data wouldn't be identical between the timestamped snap and the one named latest. I don't know whether that would matter to anyone or not.

One interesting thing that's coming in kubernetes is the notion of "data populators."
They will make it possible to create a populator that goes with SnapScheduler, effectively allowing you to use the SnapshotSchedule as the PVC's dataSource. The populator would then restore the latest snapshot when the PVC gets created.

BTW, thanks for the feedback. Glad to see it's being used!

[PSjoe]

Yeah, it was really the exact answer I needed for my use case! Well, almost exact. :)

In my particular use case, the difference between "latest" and the "date stamp" version wouldn't matter. I just want to get "as close as possible" and keep a couple of old copies "just in case". The exact time of the backup isn't nearly as relevant. So even in that short time where there's no "latest", I could always manually go back to the one just before.

And presumably, this would be something you could toggle on and off, since not everyone would need it.

Regardless, thanks for putting this together! Even as is it's a great help. If I knew how to write Go, I'd take a stab at this feature request myself. But alas, I have to "serverfault" my way though bash scripting most of the time.

[ricardolyn]

I find this useful too to have one that as the lastest snapshot. is there a plan to include this feature?

[JohnStrunk]

I don't have immediate plans to work on it, but I'd be happy to shepherd a contribution of this feature.