Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #13325 +/- ##
============================================
- Coverage 19.91% 19.91% -0.01%
- Complexity 20200 20221 +21
============================================
Files 6373 6374 +1
Lines 577230 577508 +278
Branches 70696 70748 +52
============================================
+ Hits 114974 115029 +55
- Misses 449690 449904 +214
- Partials 12566 12575 +9
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
# Conflicts: # server/src/main/java/com/cloud/vm/UserVmManagerImpl.java # ui/src/config/section/network.js
35bcb26 to
c8ac2a0
Compare
- Add network_rate column to nics table (schema-42300to42400.sql) - Add DB upgrade path: Upgrade42300to42400 registered in DatabaseUpgradeChecker - Add network_rate field and getter/setter to NicVO - Set network_rate on NicVO in NetworkOrchestrator.allocateNic() where rate is already computed, eliminating secondary per-NIC update calls - Add getNetworkRate() to Nic interface so ApiResponseHelper.createNicResponse can call result.getNetworkRate() without casting or extra DB queries - Add nic_network_rate to user_vm_view and UserVmJoinVO so listVirtualMachines reads rate from the join without extra per-NIC findNicById calls - Update UserVmJoinDaoImpl to use uvo.getNicNetworkRate() directly - Expose network_rate in NicResponse as Integer (null = unlimited) - Refresh NIC rates on VM start via refreshNicNetworkRates in UserVmManagerImpl
|
@blueorangutan package |
|
@sudo87 a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19103 |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@blueorangutan package |
|
@sudo87 a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19139 |
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Refactor versioning logic to handle four-component metadata separately. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…0 versioning cutover Cherry-picked the upstream 4.23.0.0 -> 24.0.0 version-cutover upgrade path (management server versions dropping the leading "4." from 24.0.0 onwards) so our own migration targets the real next version. Our previous Upgrade42300to42400 registered itself against "4.24.0.0", which no longer exists once the cutover lands - the project's actual next version is 24.0.0, matching pom.xml's 24.0.0-SNAPSHOT. Folded the public_nw_rate/network_rate column additions and the NetworkRateBackfill data migration into the new Upgrade42300to2400 class and its schema-42300to2400.sql, and removed the now-redundant Upgrade42300to42400/schema-42300to42400.sql.
|
@blueorangutan package |
|
@sudo87 a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19281 |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
# Conflicts: # engine/schema/src/main/java/com/cloud/upgrade/dao/Upgrade42300to2400.java # engine/schema/src/main/resources/META-INF/db/schema-42300to2400.sql
Found by actually running the 4.23.0.0 -> 24.0.0 upgrade path via RPM against a real DB, not just unit tests: - findRouterGuestNetworkRate() called NicDao.listByVmId(), but this class's DAOs are constructed outside Spring during upgrade bootstrap, and that query relies on a SearchBuilder that isn't initialized in that context, throwing an NPE that was silently caught. Every VPC/ isolated-network router's public NIC failed to backfill as a result. Replaced with a raw SQL query, matching this class's existing pattern for DAOs that aren't safe to use directly here. - backfillNicNetworkRates() only persisted a computed rate when it was greater than zero, silently skipping the legitimate "-1 (unlimited)" case - affecting ConsoleProxy/SecondaryStorageVm NICs and any NIC whose legacy rate resolved to unlimited. Left network_rate NULL instead of -1, which the API renders as blank instead of "Unlimited" until the NIC is reallocated.
nics.network_rate is an unsigned int column, so it cannot store -1; NULL is the established convention for "unlimited" there, exactly matching how the live precedence code (NetworkOrchestrator.allocateNic()) already stores it. Changing the backfill's guard to write -1 caused a real "Data truncation: Out of range value" failure, confirmed via a second real upgrade run. The original rate > 0 check (skip writing on unlimited, leaving NULL) was correct; only the router public-NIC NPE fix from the previous commit was a genuine bug.
nics.network_rate was unsigned, so the only way to represent "unlimited" was NULL, even though every response-building call site already normalizes null/non-positive to -1 for API output - meaning NULL and -1 were already behaviorally equivalent, just inconsistent at the storage layer. NetworkModelImpl.getNetworkRate() never actually returns null (always a positive rate or -1), so the null-coalescing in NetworkOrchestrator was dead code once the column can hold -1 directly. Make the column signed so it can store -1 like every other "resolved" rate value in the codebase, simplify both NetworkOrchestrator call sites to store the value as-is, and let the backfill persist -1 for NICs whose legacy rate is unlimited instead of leaving them NULL.
|
@blueorangutan package |
|
@sudo87 a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19283 |
Description
Adds an operator-configurable data transfer rate for a VPC's public/internet-facing gateway, independent of the per-tier rates that network offerings already control.
Precedence:
Also persists the effective network rate per NIC and Network and exposes the effective network rate (bandwidth throttling) configured for NICs and guest networks in the API responses and UI.
Also includes the 4.23.0.0 → 24.0.0 version upgrade path from the PR #14033, so our migration targets a version that'll actually exist. Will need reconciling once that PR lands.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Verified end-to-end in a lab: API responses, the actual libvirt bandwidth configuration on the router, and measured live throughput across a multi-tier VPC confirming tiers correctly share one capped public-gateway.
How did you try to break this feature and the system with this change?