winterhazel opened a new pull request, #13048: URL: https://github.com/apache/cloudstack/pull/13048
### Description PR #10140 changed how volume and primary storage resources are reserved in the deployment process. However, the new method has an issue in which, if the reservation of part of the storage resources fails (e.g. able to reserve a volume resource for the root disk, but unable to reserve primary storage for it), those that were previously reserved are never released. Hence, users are not able to fully utilize their configured limits. This PR fixes this issue and, additionally, adds a query to clean the stale entries to the upgrade script. It is more interesting to introduce a smarter logic to clean these stale reservations in the future without the need for upgrades (for instance, by having a heartbeat_time column for the reservations and automatically cleaning entries older than an amount of time); however, as we are very close to the release of 4.22.1, there is not sufficient time to implement and test a more complex mechanism, so I opted instead to include a simple script to already normalize environments that are affected. ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] 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 #### Bug Severity - [ ] BLOCKER - [ ] Critical - [X] Major - [ ] Minor - [ ] Trivial ### How Has This Been Tested? #### Storage resource reservation release on VM deployment failure I configured volume and primary storage limits for an account to 1 and 2 GB, respectively. Then, I attempted to deploy a VM with a 50 MB root disk and a 5 GB data disk. This process ended in failure, as there were not enough volume resources available. Before the changes, some stale volume and primary storage reservations for the root disk would remain in the database. Due to this, I was not able to deploy any more VMs for that account using these limits, even if it had only a single volume. <details> <summary> Failure on VM deployment due to insufficient volume resources </summary> <img width="1247" height="1319" alt="Screenshot from 2026-04-20 13-51-19" src="https://github.com/user-attachments/assets/ae40c63c-bcec-4fd2-bec2-53772039be1f"; /> </details> ```sql MariaDB [cloud]> select * from resource_reservation; +-----+------------+-----------+-----------------+----------+------+-------------+-----------------+---------------------+ | id | account_id | domain_id | resource_type | amount | tag | resource_id | mgmt_server_id | created | +-----+------------+-----------+-----------------+----------+------+-------------+-----------------+---------------------+ | 104 | 4 | 2 | volume | 1 | NULL | NULL | 236056202620519 | 2026-04-20 16:50:51 | | 105 | 4 | 2 | primary_storage | 52428800 | NULL | NULL | 236056202620519 | 2026-04-20 16:50:51 | +-----+------------+-----------+-----------------+----------+------+-------------+-----------------+---------------------+ 2 rows in set (0.001 sec) ``` Performing the same procedure after the changes did not result in stale reservations. ```sql MariaDB [cloud]> select * from resource_reservation; Empty set (0.001 sec) ``` #### Resource reservation on database upgrade I upgraded an environment on 4.22.0 with stale volume and primary storage reservations to 4.22.1 and validated, after the upgrade finished, that there were no more stale entries. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
