Change listVpcOfferings endpoint and createVpcOffering endpoint

[radu-todirica]

Description

Currently in cloudstack there is no way to create a VPC Offering with a selected service offering, the service offering is always null. When a VPC router is created if the service offering is null a default Service Offering is chosen.

The following changes have been added:

• listVpcOfferings endpoint will list what system service offering they were created with
• the cloudstack ui will let you pick what serviceOfferingId to use
• the cloudstack ui will let you edit the serviceOffering used by the vpcOffering

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)

Screenshots (if appropriate):

How Has This Been Tested?

Wrote a python test for testing create VPC offering with selected service offering
Steps for validation

• Create a system offering
• Create VPC Offering by specifying all supported Services and your system offering
• VPC offering should be created successfully

results.txt
runinfo.txt

[weizhouapache]

@radu-stefanache all service/disk/network/vpc offerings are not editable (except name and display text). maybe you can research on other solutions. for example, add "router offering" to vpc as a new field, or update vpc to another offering (similar as update network offering).

[DaanHoogland]

@weizhouapache i agree that offerings should not be editable as they can be in use, but what is the harm in adding the offering to the create API?

[weizhouapache]

@weizhouapache i agree that offerings should not be editable as they can be in use, but what is the harm in adding the offering to the create API?

@DaanHoogland I am ok with adding router offering to createVpcOffering, similar as createNetworkOffering.

However, the network/vpc will be shutdown if we change a network/vpc to another offering. It would be nice to create a new VR before we destroy current running VR, like @rhtyd did when restart Network/vpc.

[radu-todirica]

Thanks @weizhouapache and @DaanHoogland for your feedback. I will do the changes.

[DaanHoogland]

hope you manage @radu-stefanache . point to keep in mind uis that we can not ever allow altering offerings as they might be in use elsewhere and by other people in other locations in the system and unpredictable things happen if you allow that.
happy coding

[nathanejohnson]

@DaanHoogland so regarding the "no edit to service / disk offerings" , I'm not sure I completely understand your stance on this? In fact, there is a PR we're considering that would allow users to modify the hypervisor based disk iops / rate limiting parameters?

[DaanHoogland]

@nathanejohnson that would impact all running instances, how would you control which get impacted and in fact for which it is meant? such changes should be done on the instances or by selecting a new offering, not by altering an offering of which you don't know by who it is used.
btw this is not some secret principle I adhere, but a long standing design proinciple of cloudstack as i understand it to be. (/me loves discussion)

[nathanejohnson]

@DaanHoogland it would impact them once they restarted, yes. And I can see this being an argument around cores, ram etc. But for hypervisor based IO limits, we have no current concept of "custom", which is how people get around static cpu and memory limits today.

[DaanHoogland]

sorry @nathanejohnson , i'm on staycation so not reacting to promptly.
should the concept of custom than not be implemented, instead of trying to correctly implement hypervisor specific knobs in offerings? how you say it, it seems like it is something that should be read from the host during deploy???

[nathanejohnson]

This isn't host specific, in this case "hypervisor specific" implies that for kvm these knobs are part of the domain xml and kvm itself implements the throttling. The other option is to use some external managed storage provider - like solidfire. I do think in a perfect world these would have been implemented in such a way that it would be easy to override on a per-VM basis, such as with "custom", but that's now how it's done today, and it wouldn't be the easiest lift in the world to change it. This isn't to say I'm against the implementation. But the libvirt IO throttling functionality has worked basically the same way for quite some time now with the exception to a few additional tunables we added over the past year or so. At present, the only way to change these limits is to dip to the database, or to use a patched update service offering call.

[DaanHoogland]

@nathanejohnson is #3839 in line with your requirements? your last description let me to associate to that.

[rohityadavcloud]

ping @radu-todirica cc @kiwiflyer is this still relevant? Can you fix the conflict if so. Thanks.

[github-actions]

Hi @${author}, your pull request has merge conflicts. Can you fix the conflicts and sync your branch with the base branch?

[weizhouapache]

good feature