server: publish volume resize event for volumes#3219
Conversation
This fixes the issue that the disk offering change is not reflected in the cloud_usage table. Moves the method that published events for volumes in Ready state from the VolumeStateListener class to the orchestrateResizeVolume method in the VolumeApiService Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
|
@blueorangutan package |
|
@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-2638 |
|
@blueorangutan test |
|
@borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
Trillian test result (tid-3449)
|
yadvr
changed the title
|
@blueorangutan package |
|
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-2772 |
borisstoyanov
left a comment
borisstoyanov
left a comment
There was a problem hiding this comment.
LGTM attached test results
test_results.xlsx
|
LGTM - can see that disk offering has changed from 3 to 5 and that on the 20th, disk was used partially as type 3 and partially as type 5
|
yadvr
changed the title
5 participants
Problem: The disk offering change is not reflected in cloud_usage database table.
Root Cause: The resizeVolume API does not publish the volume disk offering change event to the
cloud_usage database table.
Solution: This issue has been fixed by refactoring the resizeVolume API to publish this disk offering change for volumes that either in Allocated or Ready state.
Moves the method that published events for volumes in Ready state from
the VolumeStateListener class to the orchestrateResizeVolume method in
the VolumeApiService.
Types of changes