bhouse-nexthop commented on PR #14112: URL: https://github.com/apache/cloudstack/pull/14112#issuecomment-6866071567
@DaanHoogland thanks, and sorry it took a while to answer the rest of your review point by point. **Separate test files.** You were right about two of the three. `CapacityManagerScaleToClusterUnitsTest` and `ConfigurationManagerOverCommitDetailTest` each tested a single method of a class that already has a main test file, so I've moved them into `CapacityManagerImplTest` and `ConfigurationManagerImplTest` (27b21a1a3bfadd1f964917db94849411e277e648). The tests themselves are unchanged. Only their names changed, so they say which method they cover. The count is the same before and after (14 moved, 897 in the capacity, allocator, planner, configuration, VM manager and KVM test classes, all passing). `VirtualMachineManagerOverCommitTest` stays where it is: after your earlier inline comment the logic was moved into its own class, `VirtualMachineManagerOverCommit`, and that file is that class's test. I've also merged main into the branch to clear the conflict, which was only in `PendingReleaseNotes`. **Functional consequences** - *What an operator sees:* two optional compute offering fields, CPU and memory overcommit ratio. In the API they are the `cpuOvercommitRatio` / `memoryOvercommitRatio` keys of `serviceofferingdetails`, the same keys used at cluster and VM scope. They are checked when the offering is created: anything that isn't a number, or is below 1, is rejected. A value higher than the cluster's is allowed and logged when a VM starts. - *Default behaviour:* if an offering doesn't set the detail, the VM runs at its cluster's ratio, exactly as today. The planner's request scaling returns the request unchanged, no memory-reclaim flag is written, and the VM's recorded ratio is the cluster's, so the start/stop charge equals the request. - *Capacity accounting:* capacity is still counted in the cluster's overcommitted units. A VM whose offering sets its own ratio is charged `size / offeringRatio * clusterRatio`. So a ratio-1 VM on a 4x cluster takes 4x the units of a same-sized neighbour, which means it really holds its full size. The ratio is resolved when the VM starts or migrates and recorded on the VM. Start, stop and the periodic recalculation all read that recorded value, so they agree. While I was there I fixed a latent mismatch: start/stop used to charge the raw size, while the recalculation already scaled by the VM's recorded ratio. Those differed whenever the cluster ratio had been changed under running VMs. - *Planner:* the per-host capacity check (`checkIfHostHasCpuCapabilityAndCapacity`, used by the host allocators, router placement and starting a VM on a chosen host) and the last-host check in `planDeployment` both ask in the same scaled units, so a VM that passes the check is charged the same amount when it starts. The cluster-level pre-filtering in `FirstFitPlanner` (cluster ordering and the disable thresholds) still uses the offering's nominal size, as before. The per-host check is the one that decides. - *KVM:* for an offering with a memory ratio of 1, its VMs get `autodeflate`/`freePageReporting` turned off on the balloon, so the guest doesn't hand memory back to the host. The balloon device stays, so memory stats still work. VMs on offerings without the detail get the same domain XML as before. - *Upgrade / existing VMs:* there is no schema change and no data migration. Existing offerings have no detail, so nothing changes for them. An offering's ratio takes effect when one of its VMs starts or migrates. A live scale keeps the ratio the VM was started under until it next starts or migrates. The one visible change for existing VMs is the accounting fix above: on a cluster whose ratio was changed after its VMs started, start/stop now charge what the periodic recalculation would have converged to anyway. The lab test of all this is in the [earlier report](https://github.com/apache/cloudstack/pull/14112#issuecomment-6740298369). -- 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]
