Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Set Full Snap renewTime to the time full snapshot was taken instead of full snap lease update time. #752

Closed
anveshreddy18 opened this issue Jul 22, 2024 · 0 comments · Fixed by #753
Assignees
Labels
area/monitoring Monitoring (including availability monitoring and alerting) related kind/enhancement Enhancement, improvement, extension status/closed Issue is closed (either delivered or triaged)

Comments

@anveshreddy18
Copy link
Contributor

Enhancement (What you would like to be added):

During update of full snapshot lease, set renewTime to the time the full snapshot was taken, instead of setting it to the time when the lease was updated as part of retry mechanism.

Motivation (Why is this needed?):

Currently if a full snapshot lease is not updated upon taking a full snapshot, PR #711 has introduced a retry mechanism where in the method heartbeat.FullSnapshotCaseLeaseUpdate that takes care of updating a full snapshot is repeatedly called until the lease is updated. This works. But with this, the renewTime in the lease is set to the time when the lease is updated, ideally this makes sense but druid consumes the renewTime to check the health of backups. So instead of just retrying the method to update the lease, we should carry forward the snapshot time to be set as renewTime even if the lease is updated x hours after the snapshot is taken. This way druid knows only about the snapshot time and need not care about whether it was updated instantly or as part of retry method.

Approach/Hint to the implement solution (optional):

@anveshreddy18 anveshreddy18 added kind/enhancement Enhancement, improvement, extension area/monitoring Monitoring (including availability monitoring and alerting) related labels Jul 22, 2024
@anveshreddy18 anveshreddy18 self-assigned this Jul 22, 2024
@gardener-robot gardener-robot added the status/closed Issue is closed (either delivered or triaged) label Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/monitoring Monitoring (including availability monitoring and alerting) related kind/enhancement Enhancement, improvement, extension status/closed Issue is closed (either delivered or triaged)
Projects
None yet
2 participants