cloudstack: Incorrect backup usage when VM is removed then re-assign to backup offering
ISSUE TYPE
- Bug Report
COMPONENT NAME
Usage
CLOUDSTACK VERSION
4.14.1.0
4.15.0.0
CONFIGURATION
Backup framework enabled
OS / ENVIRONMENT
N/A
SUMMARY
When a VM is removed from a backup offering, then re-assigned to the same backup offering, the usage record generated for the period in which these events occur has an invalid usage value, equal to the sum of the sizes of the backups.
STEPS TO REPRODUCE
Example scenario:
02:30 PM
: Create a VM and assign it to a backup offering02:35 PM
: Make backups of the VM (for a size of e.g. 1 GiB)03:15 PM
: Remove the backup offering, with the “force” option (to delete existing backups)03:30 PM
: Re-assign the VM to the backup offering03:35 PM
: Make a backup of the VM (for a size of e.g. 0.8 GiB)
To reproduce the bug, if the usage aggregation range is e.g 1 Hour (usage.stats.job.aggregation.range = 60
), make sure the steps 3, 4 and 5 are executed in the same hour.
EXPECTED RESULTS
Option 1: I would expect CloudStack usage server to:
- generate two usage records for the period between
03:00 PM
and04:00 PM
(one for each period with a backup offering) - use the fields
raw_usage
/usage_display
to show the duration of usage, and the fieldsize
to show the size of the backups (that’s the way storage usage records are generated for volumes, templates, ISOs and snashots)
+------------+---------------+------------+------------+----------+----------+------------------------+
| raw_usage | usage_display | size | start_date | end_date | usage_id | description |
+------------+---------------+------------+------------+----------+----------+------------------------+
| 0.5 | 0.5 Hrs | 1073741824 | 14:00:00 | 14:59:59 | 67 | Backup usage VM ID: 67 |
| 0.25 | 0.25 Hrs | 1073741824 | 15:00:00 | 15:59:59 | 67 | Backup usage VM ID: 67 |
| 0.5 | 0.5 Hrs | 858993460 | 15:00:00 | 15:59:59 | 67 | Backup usage VM ID: 67 |
+------------+---------------+------------+------------+----------+----------+------------------------+
Option 2: This could also be ok (even if we loose information):
+------------+---------------+------------+------------+----------+----------+------------------------+
| raw_usage | usage_display | size | start_date | end_date | usage_id | description |
+------------+---------------+------------+------------+----------+----------+------------------------+
| 1073741824 | 1.0 GiB | 1073741824 | 14:00:00 | 14:59:59 | 67 | Backup usage VM ID: 67 |
| 858993460 | 0.8 GiB | 858993460 | 15:00:00 | 15:59:59 | 67 | Backup usage VM ID: 67 |
+------------+---------------+------------+------------+----------+----------+------------------------+
ACTUAL RESULTS
Usage records:
+------------+---------------+------------+------------+----------+----------+------------------------+
| raw_usage | usage_display | size | start_date | end_date | usage_id | description |
+------------+---------------+------------+------------+----------+----------+------------------------+
| 1073741824 | 1.0 GiB | 1073741824 | 14:00:00 | 14:59:59 | 67 | Backup usage VM ID: 67 |
| 1932735284 | 1.8 GiB | 1932735284 | 15:00:00 | 15:59:59 | 67 | Backup usage VM ID: 67 |
+------------+---------------+------------+------------+----------+----------+------------------------+
Here, the raw_usage
for the period from 3 PM to 4 PM is the sum of the backup sizes, which is irrelevant (the 1 GiB backups are deleted before the creation of the 0.8 GiB backup).
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (15 by maintainers)
@Pearl1594 @rhtyd @nvazquez I created a draft pr #5259 to fix this issue. since @Pearl1594 had some work in pr #5005 , let’s work together for a solution.
Let’s discuss on the mailing list, sounds like a new behaviour/change that may require consensus on dev/users ML. cc @Pearl1594 pl start a discussion thread, thanks.