server: add account-level setting: router.hypervisor.type

[weizhouapache]

Description

This PR fixes #6084

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

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

[weizhouapache]

@blueorangutan package

[blueorangutan]

@weizhouapache a Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result: ✔️ el7 ✔️ el8 ✔️ debian ✔️ suse15. SL-JID 2851

[weizhouapache]

@blueorangutan test

[blueorangutan]

@weizhouapache a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

[blueorangutan]

Trillian test result (tid-3585)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 33309 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr6101-t3585-kvm-centos7.zip
Smoke tests completed. 92 look OK, 0 have errors
Only failed tests results shown below:

Test	Result	Time (s)	Test File

[nvazquez]

Code LGTM

[weizhouapache]

@nvazquez @borisstoyanov
I have updated this PR to add an account-level setting: router.hypervisor.type
If it is set, the virtual router will be deployed with the specified hypervisor type.

the scope of the setting is Account for now, because the router.service.offering is also an account setting.

we can discuss which scope is the best, the options are Zone, Cluster, Domain, Account, a detail to Network Offering (need to create a new network offering), a new field or detail to Service Offering, etc

[nvazquez]

Thanks @weizhouapache - I think it could be better if it is a zone-wide setting since it could contain different hypervisors clusters. What do you think @weizhouapache @borisstoyanov?

[rohityadavcloud]

Should accounts be allowed to do this? We generally don't expose any implementation/hardware settings to end accounts or domains.

[weizhouapache]

Should accounts be allowed to do this? We generally don't expose any implementation/hardware settings to end accounts or domains.

@rohityadavcloud
account-level setting can only be set by root admin in the past.
but with #4339, domain admin can change them as well.

[PaulAngus]

Hi Wei,
Could you explain why we would want this. on the face of it, it doesn't seem a good idea.
One of the biggest points of a Cloud Management Platform is to abstract the underlying hardware & hypervisor away from the users.

[weizhouapache]

Thanks @weizhouapache - I think it could be better if it is a zone-wide setting since it could contain different hypervisors clusters. What do you think @weizhouapache @borisstoyanov?

@nvazquez if it is a zone-wide setting, all networks in the zone will be impacted

[weizhouapache]

Hi Wei, Could you explain why we would want this. on the face of it, it doesn't seem a good idea. One of the biggest points of a Cloud Management Platform is to abstract the underlying hardware & hypervisor away from the users.

Hi @PaulAngus
we have a customer issue. the customer has two clusters with different hypervisors. They want to deploy user VMs in the cluster A with hypervisor A but want the VR to be deployed in the cluster B with hypervisor B.
since many years ago, cloudstack tries to deploy network VR using same deployment destination as user vm, the VRs are created with the same hypervisor as user vm, they cannot be started to another cluster because the hypervisor is different.

The workaround is, deploy another user vm C in cluster B, after network VR is started in cluster B, deploy the user vm in Cluster A. The PR aims to provide a resolution.

As said before, The scope of the new setting can be discussed. The higher level means bigger impact (e.g. Zone), the lower level means smaller impact (e.g. Network Offering or Account).

CloudStack has some settings which impact the vm/vr allocation on hardware, some are visible to users (e.g. affinity group,dedication), some are not (e.g. host tags, storage tags). the account setting (not limited to this new setting) are not visible to users, but yes to root admins and domain admins.

[rohityadavcloud]

@weizhouapache could we use tags/labels with some way to link/specify them in-network offerings be used as a means of specifying preferred hypervisor for router instead? So for ex. users using Network Offering A will get VR deployed in Hypervisor X...

[weizhouapache]

@weizhouapache could we use tags/labels with some way to link/specify them in-network offerings be used as a means of specifying preferred hypervisor for router instead? So for ex. users using Network Offering A will get VR deployed in Hypervisor X...

@rohityadavcloud
yes, that's an option, similar as what I posted in #6101 (comment)