server,engine-schema: add check for account userdata cleanup

[shwstppr]

Description

Fixes #9477

This PR add a check for userdata linked with templates not owned by the account during account cleanup

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?

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 4.03%. Comparing base (750290b) to head (dd28cba).
⚠️ Report is 44 commits behind head on 4.20.

❗ There is a different number of reports uploaded between BASE (750290b) and HEAD (dd28cba). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (750290b)	HEAD (dd28cba)
unittests	1	0

Additional details and impacted files

@@              Coverage Diff              @@
##               4.20   #11595       +/-   ##
=============================================
- Coverage     16.23%    4.03%   -12.21%     
=============================================
  Files          5657      402     -5255     
  Lines        498932    32721   -466211     
  Branches      60552     5832    -54720     
=============================================
- Hits          81016     1319    -79697     
+ Misses       408882    31247   -377635     
+ Partials       9034      155     -8879     

Flag	Coverage Δ
uitests	4.03% <ø> (+0.02%)	⬆️
unittests	?

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

☔ View full report in Codecov by Sentry.
📢 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.

[shwstppr]

@blueorangutan package

[blueorangutan]

@shwstppr 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]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 14922

[harikrishna-patnala]

@shwstppr I believe this fix will not effect the VMs that are already created using the template which previously linked to the userdata as we are saving the actual userdata in user_vm table. am I right ?

[github-actions]

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

[shwstppr]

@harikrishna-patnala I'm not sure if we save all user data in user_vm table.
This change is draft as I've not verified myself yet. It may not be needed now that we don't completely remove the userdata entry and just mark it removed

@shwstppr I believe this fix will not effect the VMs that are already created using the template which previously linked to the userdata as we are saving the actual userdata in user_vm table. am I right ?

[shwstppr]

@blueorangutan package

[blueorangutan]

@shwstppr 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]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 15799

[shwstppr]

@harikrishna-patnala #9477 was still valid so I updated changes here to prevent account deletion when a userdata owned by the account is linked templates not owned by the account

[shwstppr]

@blueorangutan package

[blueorangutan]

@shwstppr 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]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16287

[sureshanaparti]

minor nit, clgtm

[nvazquez]

Code LGTM, just a minor comment

[RosiKyu]

@blueorangutan package

[blueorangutan]

@RosiKyu 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]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16533

[RosiKyu]

Verification failed

Summary

The PR's detection logic works correctly - it identifies when userdata owned by an account is linked to templates owned by other accounts and throws a CloudRuntimeException. However, the exception is caught in cleanupAccount() and logged as a warning rather than propagating the failure. This allows the account deletion to proceed, resulting in:

1. Account marked as removed despite the conflict
2. Orphaned userdata remaining in the database
3. Template still referencing the deleted account's userdata

The CloudRuntimeException thrown by deleteUserDataForAccount() should not be caught silently. It should propagate to fail the account deletion operation and return an appropriate error to the API caller.

---

TC: Account deletion blocked when userdata is linked to another account's template

Objective
Verify that account deletion fails when userdata owned by the account is linked to a template owned by a different account.

Test Steps

1. Create a new user account testuser1
2. Register userdata testuserdata1 owned by testuser1
3. Link the userdata to admin-owned template CentOS 5.5(64-bit) no GUI (KVM) using linkUserDataToTemplate API
4. Attempt to delete the testuser1 account

Expected Result
Account deletion should fail with error: "User data owned by account linked to templates not owned by the account"

Actual Result
Account deletion returned success: true. The account was marked as removed in the database despite the exception being thrown. The userdata remains in the database (not removed) and the template still references it, creating an orphaned userdata scenario.

The PR check logic correctly detects the conflict and throws a CloudRuntimeException, but the exception is caught and logged as a warning rather than propagating to fail the account deletion.

Test Evidence

Management server log showing exception was thrown but account deletion continued:

2026-01-26 14:23:06,340 WARN  [c.c.u.AccountManagerImpl] (API-Job-Executor-1:[ctx-3f0cb0f6, job-40, ctx-79bab56d]) (logid:825ffaf4) User data IDs [2] owned by account ID 6 cannot be deleted as some of them are linked to templates [4] not owned by the account.
2026-01-26 14:23:06,341 WARN  [c.c.u.AccountManagerImpl] (API-Job-Executor-1:[ctx-3f0cb0f6, job-40, ctx-79bab56d]) (logid:825ffaf4) Failed to cleanup account Account [{"accountName":"testuser1","id":6,"uuid":"3e6df877-6d2e-4143-9398-38766b040f6a"}] due to com.cloud.utils.exception.CloudRuntimeException: User data owned by account linked to templates not owned by the account
    at com.cloud.user.AccountManagerImpl.deleteUserDataForAccount(AccountManagerImpl.java:488)
    at com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:1218)
    at com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:921)
    at com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:2125)

API response showing success despite exception:

(localcloud) > delete account id=3e6df877-6d2e-4143-9398-38766b040f6a
{
  "success": true
}

Database showing account was removed:

mysql> SELECT id, uuid, account_name, state, removed FROM account WHERE id = 6;
+----+--------------------------------------+--------------+---------+---------------------+
| id | uuid                                 | account_name | state   | removed             |
+----+--------------------------------------+--------------+---------+---------------------+
|  6 | 3e6df877-6d2e-4143-9398-38766b040f6a | testuser1    | removed | 2026-01-26 14:23:06 |
+----+--------------------------------------+--------------+---------+---------------------+

Database showing userdata still exists (orphaned):

mysql> SELECT * FROM user_data;
+----+--------------------------------------+---------------+------------+-----------+------------------------------+--------+---------------------+
| id | uuid                                 | name          | account_id | domain_id | user_data                    | params | removed             |
+----+--------------------------------------+---------------+------------+-----------+------------------------------+--------+---------------------+
|  2 | 3d7d4970-d9ee-4787-9962-9489a0b6ff35 | testuserdata1 |          6 |         1 | dGVzdHVzZXJkYXRhY29udGVudA== | NULL   | NULL                |
+----+--------------------------------------+---------------+------------+-----------+------------------------------+--------+---------------------+

Database showing template still references the userdata:

mysql> SELECT id, name, user_data_id, account_id FROM vm_template WHERE id = 4;
+----+---------------------------------+--------------+------------+
| id | name                            | user_data_id | account_id |
+----+---------------------------------+--------------+------------+
|  4 | CentOS 5.5(64-bit) no GUI (KVM) |            2 |          1 |
+----+---------------------------------+--------------+------------+

Status: FAILED

[shwstppr]

Thanks @RosiKyu for testing.
I didn't realize server first marks the account as removed and then performs the cleanup. This would require considerable changes to the account deletion flow, so I'm marking this PR as draft for now.