-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Fix calculation of the next time that Usage will execute in removeRawUsageRecords
#12518
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
base: 4.20
Are you sure you want to change the base?
Fix calculation of the next time that Usage will execute in removeRawUsageRecords
#12518
Conversation
|
@blueorangutan package |
|
@winterhazel a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 4.20 #12518 +/- ##
============================================
- Coverage 16.24% 16.02% -0.22%
- Complexity 13396 13403 +7
============================================
Files 5658 5704 +46
Lines 499169 513122 +13953
Branches 60579 64702 +4123
============================================
+ Hits 81087 82246 +1159
- Misses 409041 421774 +12733
- Partials 9041 9102 +61
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 16534 |
|
@blueorangutan package |
|
@winterhazel a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
|
||
| private TimeZone usageExecutionTimeZone = TimeZone.getTimeZone("GMT"); | ||
|
|
||
| private static final long REMOVE_RAW_USAGE_RECORDS_WINDOW_IN_MS = 15 * 60 * 1000; |
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.
@winterhazel , why the “magic” 15 minutes?
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.
never mind, traditional magic.. :(
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16535 |
Description
removeRawUsageRecordscalculates the next moment in which Usage will execute in order to prevent the removal of usage records in a window of 15 minutes before and after the Usage job executes. However, this calculation is performed incorrectly because the date is not rolled to the next day in case the initial calculated date has already passed. Due to this, if the Usage job is scheduled to execute at 00:00 and the current time is 23:59 (the job will execute in a minute), for instance, this check fails and the usage records are removed.This PR fixes the calculation.
Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
The tests were performed in a VM with its date set to 2026-01-26 GMT-3.
Before the changes
I scheduled Usage to execute at 00:00 and set the Management Server's date to 23:50. I executed
removeRawUsageRecords. I verified that the calculated execution date was 2026-01-26 00:00 (incorrect value), and that the usage records were removed.With the patch
Regarding
removeRawUsageRecords:I scheduled Usage to execute at 00:00 and set the Management Server's date to 23:50. I executed
removeRawUsageRecords. I verified that the calculated execution date was correct, and that the usage records were not removed.I scheduled Usage to execute at 00:00 and set the Management Server's date to 00:05. I executed
removeRawUsageRecords. I verified that the calculated execution date was correct, and that the usage records were not removed.I scheduled Usage to execute at 00:00 and set the Management Server's date to 23:40. I executed
removeRawUsageRecords. I verified that the calculated execution date was correct, and that the usage records were removed.I scheduled Usage to execute at 00:00 and set the Management Server's date to 00:20. I executed
removeRawUsageRecords. I verified that the calculated execution date was correct, and that the usage records were removed.Regarding the job execution time in the Usage Server itself:
I scheduled Usage to execute at 00:00 and set the Management Server's date to 23:50. I restarted the Usage Server. I verified that the calculated execution date was correct.
I scheduled Usage to execute at 00:00 and set the Management Server's date to 00:20. I restarted the Usage Server. I verified that the calculated execution date was correct.
I scheduled Usage to execute at 00:10 and set the Management Server's date to 00:05. I restarted the Usage Server. I verified that the calculated execution date was correct.
I scheduled Usage to execute at 00:10 and set the Management Server's date to 00:12. I restarted the Usage Server. I verified that the calculated execution date was correct.