You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
In addition to vpc, there is a change in precedence order for network rate for NIC and VRs being added in this PR.
For NICs:
Default used to select network rate based on below:
Bandwidth from compute offering > "vm.network.throttling.rate" config
Other NICs use:
Bandwidth from Network offering > "network.throttling.rate" config
Going forward Default NIC precedence will be used for all NICs
For VR's guest interface:
Old precendence:
Bandwidth from Network offering > "network.throttling.rate" config
New one:
Bandwidth from System offering > Network offering > "network.throttling.rate" config
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.
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?
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?
sudo87
changed the title
persist and expose effective network rate for NIC, Network and compute offering
Persist and expose effective network rate for NIC, Network and compute offering
Jun 3, 2026
❌ Patch coverage is 17.06485% with 243 lines in your changes missing coverage. Please review.
✅ Project coverage is 19.93%. Comparing base (510d0ec) to head (6438d86). ⚠️ Report is 2 commits behind head on main.
- 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
When a network offering changes, this refreshes only the network-level snapshot. Existing NIC rows keep their previous network_rate, while the replug path is limited to running VMware user VMs; other attached VMs/routers can therefore continue to expose the old rate through the new NIC API (and retain it until a later allocate/prepare). Recompute and persist the effective rate for each attached NIC as part of the offering update.
Pass explicit zero rate when creating VPC offerings
ui/src/views/offering/AddVpcOffering.vue:735
A value of 0 is the documented explicit unlimited setting, but this truthiness check omits it from createVPCOffering. On a zone with a nonzero vpc.public.network.throttling.rate, entering 0 therefore applies the zone cap instead of the requested unlimited offering. Test for presence rather than truthiness so zero is sent.
Document -1 representation for unset offering values
The response mapper now normalizes both an unset offering value and explicit 0 to -1, but this description still promises null for an unset value. That contradicts the actual API payload and the UI's -1 handling; document the -1 representation and clarify that an unset value may fall back to the zone/global default.
- importNic: persist the computed effective network rate on the NIC
instead of leaving network_rate NULL for imported NICs.
- restartVpc: only refresh the persisted public network rate snapshot
after a restart actually succeeds, not before either restart path
runs, so a failed restart can't leave a stale/premature snapshot.
- VpcOfferingResponse: fix stale doc string; the response normalizes
unset/unlimited to -1, not null.
Updating the network offering changes the persisted network-level rate here, but it never recomputes nics.network_rate for NICs already attached to this network. This leaves API responses and the applied VR bandwidth stale; in particular, a router guest NIC whose system offering has no rate should now fall back to the new network-offering rate, but will continue to expose/use its old persisted value. Update the affected NICs as part of the offering change or make the reconfiguration path persist the recomputed rate.
- Remove publicnetworkrate from updateVPCOffering; it is set only at
create time
- createVPCOffering accepts -1 or 0 (unlimited, stored as -1) or a
positive value; values below -1 are rejected
- Make vpc_offerings.public_nw_rate a signed int; NULL means the VPC
uses the zone setting vpc.public.network.throttling.rate
- Omit publicnetworkrate in the VPC offering response when not set
- Default vpc.public.network.throttling.rate to -1 and reject values
below -1
- Use since 24.0 and consistent API descriptions
- migrateVPC: copy VPC details after the tiers are migrated and skip
publicnetworkrate, which left a stale rate on the migrated VPC
- UI: allow -1 on the Add VPC offering form, drop the edit field
- Add unit tests
The reason will be displayed to describe this comment to others. Learn more.
Copilot review overview
🔵 Needs a closer look
Several moderate issues remain around stale effective-rate persistence, inconsistent API values, migration backfill performance, and integer validation.
Updating a network's offering refreshes only the network_details value here; existing NIC rows keep the old network_rate. For a VR guest NIC without a system-offering rate (and for other NIC types using the network offering), a subsequent API read still reports the old rate and the persisted NIC value can continue to be used after the offering change. Recompute and persist the effective rate for each non-removed NIC on this network as part of the offering update.
A VPC restart without cleanup does not recreate the VR, so its public
NIC keeps the rate it was prepared with. Refreshing the stored rate
there made the API report a rate that is not enforced. Refresh it only
when the VR is recreated (cleanup or makeredundant).
Also update the vm.network.throttling.rate description, as the rate
applies to every NIC of an instance, not only the default one.
Not needed: a fresh install applies all upgrade scripts after the base schema, so these columns are created there too.
NIC rates on network offering change
Not reproducible (KVM): updating the offering re-prepares the router NICs. nics.network_rate and the libvirt bandwidth follow the new offering without a manual restart, for both isolated networks and VPC tiers.
Refresh on every VPC restart
A restart without cleanup doesn't recreate the VR, so refreshing the stored rate there reported a rate that wasn't enforced. It is now refreshed only after a restart with cleanup or makeredundant.
When a network offering is changed, existing virtual-router guest NICs can get a different effective rate (unless the system offering overrides it), but this only refreshes network_details. The new NIC API fields read nics.network_rate, so those NICs retain the old value and the API/UI no longer matches the rate recomputed by getNetworkRate() at runtime. Recompute and persist the rate for each non-placeholder NIC after changing the offering.
The reason will be displayed to describe this comment to others. Learn more.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
- NetworkRateBackfill takes the connection of the upgrade, like the
other upgrade steps
- In the network response, take the network rate from the details
already loaded for admins instead of querying it again
The reason will be displayed to describe this comment to others. Learn more.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
sudo87
changed the title
DaanHoogland
moved this from Backlog
to conflict/waiting for author
in CloudStack Testing
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:
In addition to vpc, there is a change in precedence order for network rate for NIC and VRs being added in this PR.
For NICs:
Default used to select network rate based on below:
Other NICs use:
Going forward Default NIC precedence will be used for all NICs
For VR's guest interface:
Old precendence:
New one:
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.
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?