[DaanHoogland]

Description

When a project-owned instance is opened outside its project (Default view, or another project selected), several lists on the instance page come up empty or show the caller's own resources instead of the project's. The list APIs skip project resources unless the request names a project, and these calls did not send one.

Each call now sends the instance's own projectid:

• volumes: the instance Volumes tab, and the volume lists in the snapshot, destroy and migrate dialogs (listVolumes)
• networks: the Add network to instance dialog on the NICs tab (listNetworks)
• security groups: the Change security groups dialog and the Edit instance form (listSecurityGroups); SecurityGroupSelection gets an optional projectId prop, so the deploy wizards keep using the selected project
• instance groups: the Edit instance form (listInstanceGroups)

The instance's own project is used rather than projectid=-1, because -1 only reaches the caller's own account and the projects the caller is a member of, which would hide other accounts' resources from a domain admin. An instance outside any project sends no projectid, so its requests are unchanged. The project view keeps working as before: the request interceptor only adds the selected project when a call has none.

The Add network dialog also no longer throws when there is no network left to offer.

The VolumesTab spec comes from #14158 (without its GiB label test, which depends on a change that is not on 4.20).

Fixes #14572
Fixes #14573
Fixes #14070

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
• Test (unit or integration test code)

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?

• VolumesTab.spec.js covers root admin and domain admin callers in Default view, in the instance's project and in another project, plus instances outside any project and system VMs. Without the fix, the three cases for a project instance outside its project fail.
• Headless Chrome against a dev management server, with the instance response rewritten to carry a projectid: the Volumes tab sends projectid=<project>; for an instance outside any project the request is unchanged.
• eslint on all changed files.

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

Checked that an explicit projectid wins over the selected project in the request interceptor and that an undefined one falls back to it, so the project view and instances outside any project send the same requests as before. SecurityGroupSelection drops account/domainid when a project is passed, since the API rejects account together with projectid.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 16.47%. Comparing base (e6f193d) to head (d85ab4e).

Additional details and impacted files

@@             Coverage Diff              @@
##               4.20   #14581      +/-   ##
============================================
+ Coverage     16.45%   16.47%   +0.01%     
- Complexity    13710    13714       +4     
============================================
  Files          5669     5669              
  Lines        501734   501737       +3     
  Branches      60961    60967       +6     
============================================
+ Hits          82584    82655      +71     
+ Misses       409895   409819      -76     
- Partials       9255     9263       +8     

Flag	Coverage Δ
uitests	4.28% <ø> (+0.11%)	⬆️
unittests	17.33% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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

@1fanwang, please review my version of your fix here.

[blueorangutan]

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

[DaanHoogland]

@blueorangutan test

[blueorangutan]

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

[blueorangutan]

[SF] Trillian test result (tid-17490)
Environment: kvm-ol8 (x2), zone: Advanced Networking with Mgmt server ol8
Total time taken: 54797 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr14581-t17490-kvm-ol8.zip
Smoke tests completed. 141 look OK, 0 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File

[bddvlpr]

Unsure if it's something wrong on my setup but I cannot see templates on the "Default view" anymore without the following patch.

diff --git a/ui/src/views/compute/DeployVM.vue b/ui/src/views/compute/DeployVM.vue
index 72cb74399d..dba8501023 100644
--- a/ui/src/views/compute/DeployVM.vue
+++ b/ui/src/views/compute/DeployVM.vue
@@ -1007,7 +1007,7 @@ export default {
         groups: false
       },
       owner: {
-        projectid: store.getters.project?.id,
+        projectid: store.getters.project?.id || null,
         domainid: store.getters.project?.id ? null : store.getters.userInfo.domainid,
         account: store.getters.project?.id ? null : store.getters.userInfo.account
       },

The rest seems to work. I can see the resources from the default view while they are owned by a project.

[DaanHoogland]

@bddvlpr , thanks for the finding, I'll look into that and update.

[DaanHoogland]

@bddvlpr, it wasn't you/your env, but a conflict with an old PR. I added a fix. hope all works now.

[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/14581 (QA-JID-1012)

[vanecka]

Good morning, @DaanHoogland,

Thank you for the fix. Apologies for taking so long to test; I first tried to (remotely through IPMI) install a new physical development area, but had issues compiling the code (especially failing tests such as LDAP, though unrelated to this incident). To avoid delaying the testing above, I ran it in the provided environment.

With the provided QA link above, I was able to test this.
The behaviour was as expected, and I was able to add a new network to a project and add multiple NICs (guest networks belonging to the same project) to the VM.

I can also confirm that it fixes #14572.

[DaanHoogland]

@nvazquez

With the provided QA link above, I was able to test this. The behaviour was as expected, and I was able to add a new network to a project and add multiple NICs (guest networks belonging to the same project) to the VM.

I can also confirm that it fixes #14572.

can you review?

[vanecka]

Good morning, @DaanHoogland,

After reviewing your proposed code changes (apologies; I have some coding experience but am not a coder by trade), I noticed a potential issue. I have made the following observations:

Observation 1

1. When a VM is created and owned by a user.
2. An Instance Snapshot is made.
3. The user can view, revert and manage the snapshot.
4. The ownership of the VM is changed to a project.
5. The user’s Snapshot is still present, but the user (correctly?) remains its owner.
6. Another Instance Snapshot is taken, and the project becomes its owner… however, the second (project) instance snapshot is not displayed in the normal view
7. The Instance Snapshot is correctly visible in the Compute -> Instance Snapshots view when the view Project toggle is enabled.

Suggestion: The above scenario does not lead to too many functional issues, and perhaps adding the tests you ran to include, e.g., project.id ? project : {}, could be an "easy/quick" fix to display the normal Instance Snapshots view as well.

However, the following is a more "drastic" potential issue that is present/introduced.

Observation 2:

A user-owned instance with a Volume snapshot exists.
When attempting to change the VM owner to a project, the process fails because a user-owned volume snapshot exists.
When deleting the snapshot(s), the VM ownership can be changed.

Suggestion: Consider changing the volumes and their snapshots’ ownership before changing the instance’s ownership. However, I am not sure if it would be possible without a chase condition. Also, I am not sure if this (changing all the ownerships of the VM and its related objects) is the expected behaviour. Should snapshot ownership ever be transferred between users and projects? If not, then this "bug" will persist.

[vanecka]

On a side note, the proposed fix also fixes a possibly unknown issue. Without the fix, it is not possible to make a volume snapshot of a project-owned volume in the UI. When a project-owned VM is viewed and a volume snapshot is attempted, the volume dropdown list is empty. When attempting to perform the action from Storage -> Volumes -> selecting the specific volume and then clicking on Snapshot, it produced an error: “Failed to create Snapshot due to an internal error creating Snapshot for volume”.

[1fanwang]

@1fanwang, please review my version of your fix here.

The VolumesTab change and its new tests match mine apart from the API helper name that 4.20 uses. I did not review the other files in this pull request. I agree with closing the 4.22 pull request in favour of this one, so I have closed it.

[DaanHoogland]

Thanks @vanecka,

Observation 1: same cause as the rest of this PR: the Instance Snapshots tab (and the Backups tab) on the instance page didn't send the instance's project. Both now do, so a project-owned instance's snapshots and backups show up outside the project view as well. Note that a snapshot taken while the instance was still yours stays owned by you, so it shows under Compute → Instance Snapshots in the Default view rather than on the (now project-owned) instance's tab.

Observation 2: that's deliberate server-side behaviour: assigning an instance to another owner is refused while its volumes have snapshots ("Detach volume or remove snapshots for the volume before assigning VM to another user"). Whether snapshots should move along with the instance is a fair question, but it's a backend change outside the scope of this UI fix. Could you open a separate issue for it?
On this, I would refuse it, because a snapshot is a first class citizen in cloudstack with a lifecycle and owner not tightly coupled to the volume/instance it is a snapshot from.

On the side note: nice and bummer ;). Glad the snapshot dialog works now. The "internal error creating Snapshot" issue is worth its own issue I think. I would like not to creep the scope of this PR for it. Can you reproduce it and add some logging information to the issue, if you create it?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud