When importing back ups in to a cluster from object storage, the Kubernetes API server assigns a new creation time stamp to the Backup resource. This can be confusing when importing backups from a previous cluster and seeing that the creation times don't match.
Using the StartTimestamp field makes this consistent across all clusters.
-- ORIGINAL ISSUE --
What steps did you take and what happened:
I've created an scheduled backup running the command ark create schedule myns-backup --schedule="30 * * * *" --include-namespaces myns to try to create a backup for a given namespace.
After few hours, if I run ark backup get, I can see the following:
NAME STATUS CREATED EXPIRES SELECTOR
myns-backup-20180927093049 Completed 2018-09-27 11:30:49 +0200 CEST 29d <none>
myns-backup-20180927083029 Completed 2018-09-27 10:30:29 +0200 CEST 29d <none>
myns-backup-20180927073027 Completed 2018-09-27 09:30:27 +0200 CEST 29d <none>
myns-backup-20180927064327 Completed 2018-09-27 08:43:27 +0200 CEST 29d <none>
myns-backup-20180926163024 Completed 2018-09-26 18:30:24 +0200 CEST 29d <none>
myns-backup-20180926153024 Completed 2018-09-26 17:30:24 +0200 CEST 29d <none>
myns-backup-20180926143024 Completed 2018-09-26 16:30:24 +0200 CEST 29d <none>
myns-backup-20180926142953 Completed 2018-09-26 16:29:53 +0200 CEST 29d <none>
Later, I deployed Ark in other cluster with the same bucket configuration. However, if I ran the same command, it will show you this:
NAME STATUS CREATED EXPIRES SELECTOR
myns-backup-20180927093049 Completed 2018-09-27 12:11:40 +0200 CEST 29d <none>
myns-backup-20180927083029 Completed 2018-09-27 12:11:40 +0200 CEST 29d <none>
myns-backup-20180927073027 Completed 2018-09-27 12:11:40 +0200 CEST 29d <none>
myns-backup-20180927064327 Completed 2018-09-27 12:11:40 +0200 CEST 29d <none>
myns-backup-20180926163024 Completed 2018-09-27 12:11:40 +0200 CEST 29d <none>
myns-backup-20180926153024 Completed 2018-09-27 12:11:40 +0200 CEST 29d <none>
myns-backup-20180926143024 Completed 2018-09-27 12:11:40 +0200 CEST 29d <none>
myns-backup-20180926142953 Completed 2018-09-27 12:11:40 +0200 CEST 29d <none>
The creation date doesn't match with the actual creation date of the scheduled backup in the original cluster.
What did you expect to happen:
See the actual date when the backup was created.
Environment:
ark version): Version: v.0.9.5kubectl version): v1.10.7Thanks for the report @marctc.
I think what you're seeing here is Ark in the 2nd cluster importing the backup JSON from the bucket, then registering the Backup objects in the API server of the new cluster, which updates the creation timestamp for that copy.
@heptio/ark-team @rosskukulinski Does it make sense to have our own, independent creation timestamp so we have a record of what the backup was originally made, instead of just when it was introduced to the cluster?
Yes, I think this is a good idea. I believe we previously discussed it although I don't remember where/when.
Yep - we definitely discussed and I'm +1 to doing this. It would fit nicely into v0.11.
Actually. we already have a StartTimestamp in the status. We probably just need to update the CLI to display it!
Sounds like y'all are already set, but a +1 from me as well. Ties in nicely to the work scheduled for 0.11, so +1 from me for the milestone as well.
Can I help to fix this? I'm able to help you
Yes please & thanks!
On Fri, Sep 28, 2018 at 4:18 AM Marc Tudurà notifications@github.com
wrote:
Can I help to fix this? I'm able to help you
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/heptio/ark/issues/883#issuecomment-425359824, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAABYiIKoivwDtPZ9BUMcLAlmWVKkw_fks5ufdttgaJpZM4W8hzU
.
@marctc let me know when you start on this so I can move it to in-progress.
I'm working on it. You can move it.
Most helpful comment
Can I help to fix this? I'm able to help you