This repository has been archived by the owner on Jun 23, 2022. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
BREAKING CHANGE: fix behavior when backup period less than 1day #724
base: master
Are you sure you want to change the base?
BREAKING CHANGE: fix behavior when backup period less than 1day #724
Changes from all commits
8b4002b
f7b55f4
c82ac62
3fbab01
c149b5c
f62dc23
087663e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding
context_ptr->has_backup_history()
condition, it means if the policy has already generated the backup, its start time can not be modified. Could you please explain why it should not be modified to me?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because
start_time
only indicates the first time to start backup, if we have already started a backup, we shouldn't modify it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For once backup, start_time indicates the first time to start backup, for periodical backup, I think it should be allowed to be updated, it indicates this round time to start backup, it is controlled by last start time and backup interval. Making start_time allowed to be updated, it will make function flexible, I recommend remain it if it won't make code too hard to understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The start time of subsequent backups is only related to
last_backup_start_time
andbackup_interval_secends
, if users want to modify next backup time, they could modifybackup_interval_secends
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you almost persuade me. Let me take an example to explain, there were a policy whose start time is 1:00, interval time is 1 day, if we would like update it to backup everyday 2:00. In this case, we wouldn't update interval time, if we don't provide updating start_time, we can only create another policy or update interval twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let‘s imagine how would user use this feature, maybe it's almost like how would you set you clock, there is no such a configurable "interval" concept, the interval should always be fixed value like day(or week, month, etc).
If user want to backup multiple times in one day, she should set multiple policies. On the other hand, I believe backup multiple times a day isn't a regular requirement, we don't need to make our design and code too complex to satisfy it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the design and code is complex.
start_time
is the first time to start a backup of a policy,backup_interval_seconds
is interval between two backups, which is quite easy to understand. If users want to modify start_time, they should create another policy.If we all agree that we should keep
backup_interval_seconds
, then any interval could be set, we shouldn't only support the fixed interval(day/week/month).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's better to change the type of hour and minute to
uint8_t
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dsn::utils::time_ms_to_date_time
useint32_t
for hour, min, sec, so we also useint32_t
here.Maybe we should consider use
uint8_t
to replaceint32_t
indsn::utils::time_ms_to_date_time
, if not , even if we changed interger type here, type conversions would still be needed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is too tricky. I don't want any test code appears in such way.
Try this: https://github.com/XiaoMi/rdsn/blob/master/include/dsn/utility/fail_point.h
When you in test calling
fail::cfg("should_start_backup", return())
, and this func will return true.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually we didn't call
should_start_backup
directly in tests, we calledissue_new_backup_unlocked
and expected starting a new backup inpolicy_context_test.test_app_dropped_during_backup
.