Update usage when scaling vms #7011

JoaoJandre · 2022-12-21T13:04:31Z

Description

When scaling a VM, the new details of the compute resources (memory, CPU speed, and CPU cores) are updated in the database after generating the usage event. This way, the usage events are generated with outdated details. Usage uses those events while generating entries in cloud_usage.usage_vm_instance and cloud_usage.cloud_usage, however, as in the scaling the details are updated after generating the events, the entries for the VM in cloud_usage.usage_vm_instance are always outdated after the scaling, as well the entries in cloud_usage.cloud_usage. In order to make Usage generate the proper entries, operators must stop and start the VM again (generating events of stop and start with the current VM compute resources' state).

This PR intends to fix this behavior by updating the details before generating the usage event, making the events synchronized with the current VM compute resources' state.

Types of changes

Breaking change (fix or feature that would cause existing functionality to change)
New feature (non-breaking change which adds functionality)
Bug fix (non-breaking change which fixes an issue)
Enhancement (improves an existing feature and functionality)
Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Major
Minor

Bug Severity

Screenshots (if appropriate):

How Has This Been Tested?

I set the usage.stats.job.aggregation.range setting to 1 minute to speed up the testing process, then I created a new VM with a constrained offering, and started scaling it.

Before this change, the entries in cloud_usage.usage_vm_instance and cloud_usage.cloud_usage would contain the memory, CPU speed, and CPU cores of the VM from before the last scaling, e.g., after the first scaling, the entries would have the original details, after the second scaling, the entries would have the details from the first scaling, and so on.

After this change, when dynamic scaling a VM, the events and entries in cloud_usage.usage_vm_instance and cloud_usage.cloud_usage are generated properly.

codecov · 2022-12-21T14:12:45Z

Codecov Report

Merging #7011 (bd79b64) into main (cc676cb) will increase coverage by 0.01%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##               main    #7011      +/-   ##
============================================
+ Coverage     11.27%   11.29%   +0.01%     
- Complexity     7289     7308      +19     
============================================
  Files          2492     2494       +2     
  Lines        246812   246877      +65     
  Branches      38563    38577      +14     
============================================
+ Hits          27833    27884      +51     
- Misses       215394   215400       +6     
- Partials       3585     3593       +8

Impacted Files	Coverage Δ
...n/java/com/cloud/vm/VirtualMachineManagerImpl.java	`0.00% <0.00%> (ø)`
.../src/main/java/com/cloud/vm/UserVmManagerImpl.java	`6.75% <0.00%> (-0.01%)`	⬇️
...in/java/com/cloud/server/ManagementServerImpl.java	`5.19% <0.00%> (-0.01%)`	⬇️
...va/com/cloud/deploy/DeploymentPlanningManager.java	`100.00% <0.00%> (ø)`
...k/engine/cloud/entity/api/VMEntityManagerImpl.java	`0.00% <0.00%> (ø)`
...k/affinity/NonStrictHostAntiAffinityProcessor.java	`100.00% <0.00%> (ø)`
...stack/affinity/NonStrictHostAffinityProcessor.java	`71.79% <0.00%> (ø)`
.../cloudstack/affinity/AffinityGroupServiceImpl.java	`38.75% <0.00%> (+0.29%)`	⬆️
...om/cloud/deploy/DeploymentPlanningManagerImpl.java	`28.92% <0.00%> (+0.86%)`	⬆️
... and 2 more