[UI] Add option to specify account/project while deploying VMs and creating networks

[BryanMLima]

Description

This PR adds a new component (OwnershipSelection) to specify the account/project when creating a VM and networks (can also be used for other resources in the future). This component makes it easy for operators with roles Admin and Domain Admin to create VMs for any account and/or project that it has permission.

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)
• build/CI

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?

I deployed a number of VMs using different accounts and projects in different domains.

How did you try to break this feature and the system with this change?

I tried to verify that the UI only showed the permissions according to the account/project selected.

[DaanHoogland]

@BryanMLima , have you also logged in as the other user to manipulate/delete the resources created? (nice feature btw)

[DaanHoogland]

@blueorangutan ui

[blueorangutan]

@DaanHoogland a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

[blueorangutan]

UI build: ✔️
Live QA URL: https://qa.cloudstack.cloud/simulator/pr/8919 (QA-JID-313)

[DaanHoogland]

It doesn't work in qa. maybe due to an older backend.

[DaanHoogland]

@blueorangutan package

[blueorangutan]

@DaanHoogland a [SL] 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 [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 9272

[DaanHoogland]

@blueorangutan test alma9 kvm-alma9 keepEnv

[blueorangutan]

@DaanHoogland a [SL] Trillian-Jenkins test job (alma9 mgmt + kvm-alma9) has been kicked to run smoke tests

[blueorangutan]

[SF] Trillian test result (tid-9846)
Environment: kvm-alma9 (x2), Advanced Networking with Mgmt server a9
Total time taken: 50560 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr8919-t9846-kvm-alma9.zip
Smoke tests completed. 127 look OK, 2 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File
test_01_events_resource	Error	313.81	test_events_resource.py
test_01_events_resource	Error	313.82	test_events_resource.py
test_04_deploy_vm_for_other_user_and_test_vm_operations	Failure	97.86	test_network_permissions.py
ContextSuite context=TestNetworkPermissions>:teardown	Error	1.67	test_network_permissions.py

[DaanHoogland]

tested ok, Note that during VM deployment the target user must already have a network to deploy the VM in or there will be no option to the admin to deploy

[BryanMLima]

tested ok, Note that during VM deployment the target user must already have a network to deploy the VM in or there will be no option to the admin to deploy

@DaanHoogland, thanks for testing. In the view of VM deploy, you can create a new network and specify the domain and account, therefore, there is no need to pre-create the network for the account.

@BryanMLima , have you also logged in as the other user to manipulate/delete the resources created? (nice feature btw)

Yes, I was able to manage the resources (VM and network) as expected.

[KlausDornsbach]

lgtm, also tested manipulating the VMs in the user end in both domain and project scopes and it is working fine.
Tested stopping, resuming, rebooting, scaling and deleting

[weizhouapache]

good improvement

code lgtm, not tested yet

[DaanHoogland]

@BryanMLima are you going to do more work or can we merge?

[BryanMLima]

@BryanMLima are you going to do more work or can we merge?

I added the component to the Isolated and L2 networks forms (shared networks already has the scope field, so I didn't want to change that). Now, root and domain admins can also create network to any account and project while deploying VMs (and when only creating networks, as it is the same component).

We just need another round of tests for this one.

[BryanMLima]

@DaanHoogland, I also removed the duplicate fields mentioned in #6442 (comment).

[KlausDornsbach]

Nice addition. Tested, it works fine for the cases aforementioned

[DaanHoogland]

@blueorangutan ui

[blueorangutan]

@DaanHoogland a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

[blueorangutan]

UI build: ✔️
Live QA URL: https://qa.cloudstack.cloud/simulator/pr/8919 (QA-JID-318)

[DaanHoogland]

@blueorangutan ui

[blueorangutan]

@DaanHoogland a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

[blueorangutan]

UI build: ✔️
Live QA URL: https://qa.cloudstack.cloud/simulator/pr/8919 (QA-JID-330)

[DaanHoogland]

tested ok, and clgtm

[BryanMLima]

@weizhouapache @KlausDornsbach, can you guys have a look at this PR with the latest change?

[vladimirpetrov]

@blueorangutan package

[blueorangutan]

@vladimirpetrov a [SL] 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 [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 9837

[vladimirpetrov]

LGTM based on manual testing. Tested VMs and all three network types with different accounts, projects and domains.