[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)
• [x] 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
• [x] 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: :heavy_check_mark: 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

[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

[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 https://github.com/apache/cloudstack/pull/6442#discussion_r1575706183.

[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: :heavy_check_mark: Live QA URL: https://qa.cloudstack.cloud/simulator/pr/8919 (QA-JID-318)

[DaanHoogland]

@BryanMLima looks good, one issue; if I choose to create in domain A user a and then choose to create a network in domain B I get an error. This makes sense but the error looks like:

We can keep this out of scope for this work. JFYI

[BryanMLima]

@BryanMLima looks good, one issue; if I choose to create in domain A user a and then choose to create a network in domain B I get an error. This makes sense but the error looks like:

We can keep this out of scope for this work. JFYI

Thanks for testing @DaanHoogland, I got this error in the QA environment, though it is using the 4.19 branch to build it. However, when I built locally with the main branch, this situation does not occur, I am able to create a network for a different account in the deployment view.

Could you reproduce this error when building locally? This might be a problem with the QA environment.

[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.

[DaanHoogland]

Thanks for testing @DaanHoogland, I got this error in the QA environment, though it is using the 4.19 branch to build it. However, when I built locally with the main branch, this situation does not occur, I am able to create a network for a different account in the deployment view.

Could you reproduce this error when building locally? This might be a problem with the QA environment.

I actually think it should fail (while deploying in domain A creating a network in domain B), but i'll give it a go anyway.

[blueorangutan]

Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 9404

[blueorangutan]

[SF] Trillian Build Failed (tid-9988)

[blueorangutan]

[SF] Trillian Build Failed (tid-9989)

[BryanMLima]

Thanks for testing @DaanHoogland, I got this error in the QA environment, though it is using the 4.19 branch to build it. However, when I built locally with the main branch, this situation does not occur, I am able to create a network for a different account in the deployment view. Could you reproduce this error when building locally? This might be a problem with the QA environment.

I actually think it should fail (while deploying in domain A creating a network in domain B), but i'll give it a go anyway.

The DeployVM view utilizes the component CreateNetwork, indirectly. And the CreateNetwork component is agnostic, therefore, I do not see a problem allowing privilege users to create a network different from the VM's owner — even if it does not make sense. This was already the previous behaviour, the ownership component just gave it more flexibility allowing to create for projects as well.

[DaanHoogland]

Did some more testing @BryanMLima the illusive "Request failed." actually happens when selecting a domain in your dialog that doesn't contain any account/users.