-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Allow to configure root disk size via Service Offering (diskoffering of type Service). #4341
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
Allow to configure root disk size via Service Offering (diskoffering of type Service). #4341
Conversation
|
@blueorangutan package |
|
@GabrielBrascher a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔centos7 ✔centos8 ✔debian. JID-2074 |
|
@blueorangutan package |
|
@DaanHoogland a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔centos7 ✔centos8 ✔debian. JID-2246 |
|
Ping for review: @svenvogel @rhtyd @andrijapanicsb @abhinandanprateek @ravening @sureshanaparti @slavkap @kiwiflyer @weizhouapache @RodrigoDLopez @Pearl1594 @wido and others. |
|
Code LGTM |
| @Parameter(name = ApiConstants.SERVICE_OFFERING_DETAILS, type = CommandType.MAP, description = "details for planner, used to store specific parameters") | ||
| private Map details; | ||
|
|
||
| @Parameter(name = ApiConstants.ROOT_DISK_SIZE, type = CommandType.LONG, required = false, description = "the Root disk size in GB.") |
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.
Do we need since parameter here?
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.
Sounds like a good place to add since ;)
Thanks for the heads up @ravening!
| throw new InvalidParameterValueException(String.format("The Root disk size is of %s GB but it must be greater than 0.", rootDiskSizeInGiB)); | ||
| } else if (rootDiskSizeInGiB != null) { | ||
| long rootDiskSizeInBytes = rootDiskSizeInGiB * GiB_TO_BYTES; | ||
| offering.setDiskSize(rootDiskSizeInBytes); |
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.
An optimization suggestion here. You can write below one liner since rootDiskSizeInBytes is not used anywhere else
offering.setDiskSize(rootDiskSizeInGiB * GiB_TO_BYTES)
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.
@ravening that does not make any difference. The JVM feeds its bytecodes to the Just-In-Time compiler (JIT) which will already take care of doing such optimization (among many others).
I did that way because of 2 reasons, one tecnical and the other a personal option: (i) in case of remote debugging connected via JVM it helps on changing a variable value in runtime; (ii) I prefer that way for code readability.
| } | ||
|
|
||
| private void checkIfVolumeIsRootAndVmIsRunning(Long newSize, VolumeVO volume, VMInstanceVO vmInstanceVO) { | ||
| if (!volume.getSize().equals(newSize) && volume.getVolumeType().equals(Volume.Type.ROOT) && !State.Stopped.equals(vmInstanceVO.getState())) { |
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.
Any specific reason why we are not allowing resizing when vm is running?
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.
@ravening good question.
This was done to avoid users thinking that the service offering was updated correctly. Unfortunatelly, it is necessary to Stop/Start the VM, otherwise IOps updates would not take effect, for example. Considering that this is a service offering update command, then we need to take such situations into account.
Additionally, not all operation systems support dynamic memory scaling.
|
@Pearl1594 thanks for bringing that up. I have noticed a few issues when updating disk offering details via Currently CloudStack UI uses |
|
So @GabrielBrascher would it make sense to deprecate : changeServiceForVirtualMachine - or probably always call scaleVirtualMachine API in Primate - just as we currently do in the Legacy CloudStack UI? as scaleVirtualMachine handles it both for stopped and running VMs |
|
@blueorangutan test |
|
@DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
@Pearl1594 that might make sense indeed. There is also this issue: #3110. On both cases scaling works but the change command does not. |
|
Trillian test result (tid-3047)
|
|
A couple of conflicts emerged, I will sort them out later today. |
|
@blueorangutan package |
|
@blueorangutan package |
|
@GabrielBrascher a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔centos7 ✔centos8 ✔debian. JID-2287 |
|
@pearl @ravening @GabrielBrascher is this good to go (after smoke tests) or should we move it to 4.16? |
|
@DaanHoogland functionality wise LGTM. However, it wouldn't work entirely as expected with Primate because of the invocation of the changeServiceForVirtualMachine API for a stopped VM as opposed to scaleVirtualMachine. |
|
@blueorangutan test |
Service Offering can then have a root disk size configured. On such a case the Root Volume can only be resized when changing to another Service Offering with a Root disk size equals or larger than the current one.
3324b0c to
4f6f7f0
Compare
|
@blueorangutan package |
|
@GabrielBrascher a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Synced against master (again), travis is passing now. |
|
Packaging result: ✔centos7 ✔centos8 ✔debian. JID-2309 |
|
@blueorangutan test |
|
@DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
Trillian test result (tid-3106)
|
| _itMgr.checkIfCanUpgrade(vmInstance, newServiceOffering); | ||
|
|
||
| DiskOfferingVO newROOTDiskOffering = _diskOfferingDao.findById(newServiceOffering.getId()); | ||
| // Check if the new service offering can be applied to vm instance |
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 comment could be a method name instead canServiceOfferingBeAppliedToInstance(...)
|
@PaulAngus this feature has been long waiting and meets merge requirements. leave it with the RM. |
Yes! Especially in a public cloud (Like PCextreme's) this is very useful. Why? It's not always a good thing that end-users (API users) can specify the root disk size. This way they can create a VM with 1GB of memory and a 10TB disk. This can cause problems like small DoS attacks on hypervisors or resources going out of balance. The provider should be able to dictate the exact ServiceOfferings and DiskOfferings users can deploy so that billing can also be done properly and clearly. |
|
@DaanHoogland as mentioned earlier that Primate needed some changes to make it work as the legacy UI - apache/cloudstack-primate#818 addresses that concern. With that having merged, this is good to go. Thanks |
|
tnx @Pearl1594 . @PaulAngus only 300 lines so I'll merge |
…of type Service). (apache#4341)
…of type Service). (apache#4341)
Description
Service Offering allows ADMINs to set multiple parameters such as IOPS, memory, and CPU; however, we still are not able to configure the Root Disk size of a VM via service Offering.
This PR adds control over the Root disk size and therefore helps providers that want to enforce the root disk size in the same way that it is done with compute offering.
How does it work?
To easily view all possible service offering resizing, the following table shows if such offering migration is supported:
How users can resize the root volume if the VM was deployed with a Root disk size configured via its Service offering?
Types of changes
Screenshots (if appropriate):
Setting root disk size for service offering via UI

How Has This Been Tested?
Tests:
Created the following service offerings (via API and also via UI):
Executed following tests
1. Test root volume resize.
Expected result: not allowed to resize
Steps:
a - deploy a VM with any of the root size configured offerings (e.g. 5GB)
b - Change root volume size
c - not allowed
2. Test resize via service offering.
Expected result: allow 5GB -> 10GB, and 10 GB -> 15, fail to "dowsize" from 10GB -> 5GB
Steps:
a - deploy VM with offering 5GB
b - Stop VM
c - Change Service offering to 10GB
d - Change offering back to 5GB, fails (as expected)
e - Change offering to 15GB
3. Test resize via offering to a Service offering with the default root size (0 GB) and then customize the volume
Expected result: allow 5GB -> 0GB, successfully change the root volume to a custom size
Steps:
a - deploy VM with offering 5GB
b - Stop VM
c - Change Service offering to 0GB
d - resize volume to custom size, e.g 50 GB