Damans227 commented on code in PR #14108:
URL: https://github.com/apache/cloudstack/pull/14108#discussion_r4274443755
##########
server/src/main/java/org/apache/cloudstack/cluster/ClusterDrsServiceImpl.java:
##########
@@ -761,6 +787,47 @@ void processPlans() {
}
}
+ /**
+ * Checks a planned migration against the placement rules as they stand
now.
+ *
+ * A plan is generated once and executed later, so state can have moved
on: VMs may have been
+ * created, migrated or destroyed in between. Anti-affinity in particular
is only meaningful
+ * against current placements, and nothing downstream re-checks it -
migrateVirtualMachine does
+ * not enforce affinity groups.
+ *
+ * Checked for every VM, not only those in an affinity group:
applyAffinityConstraints also
+ * applies DPDK and dedicated-resource exclusions, which apply regardless
of group membership.
+ * A refusal here is therefore not necessarily about an affinity group.
+ *
+ * @param vm
+ * the VM the plan wants to move
+ * @param destHost
+ * where the plan wants to move it
+ * @param dispatched
+ * migrations already queued by this run, which the database does
not reflect yet
+ * @param dispatchedSourceHosts
+ * hosts those queued migrations have not actually left yet
+ * @return true when the migration should not go ahead
+ */
+ protected boolean destinationViolatesAffinity(VirtualMachine vm, Host
destHost, List<VirtualMachine> dispatched,
+ List<Long> dispatchedSourceHosts) {
+ if (vm.getHostId() == null) {
+ logger.debug("VM {} is no longer running, so its planned migration
is out of date", vm);
+ return true;
+ }
+ if (dispatchedSourceHosts.contains(destHost.getId())) {
Review Comment:
that covers it, only vms in the same group hold the move back now
##########
server/src/main/java/org/apache/cloudstack/cluster/ClusterDrsServiceImpl.java:
##########
@@ -432,6 +434,29 @@ private List<Ternary<VirtualMachine, Host, Host>>
getMigrationPlans(
return migrationPlan;
}
+ /**
+ * Turns the non-strict affinity preferences recorded on the plan into
exclusions.
+ *
+ * Non-strict groups express themselves by lowering a host's priority
rather than by excluding
+ * it, and DRS only reads the exclude list - so the preference was being
discarded. Rebalancing
+ * is never a reason to break it: the VM is already running somewhere that
satisfies the group,
+ * and leaving it there is always available to DRS. "Non-strict" means the
rule may be broken
+ * when there is nowhere else to put a VM, which cannot arise while merely
rebalancing.
+ */
+ protected void excludeHostsDispreferredByAffinity(DeploymentPlan plan,
ExcludeList excludes) {
+ Map<Long, Integer> priorities = plan.getHostPriorities();
+ if (MapUtils.isEmpty(priorities)) {
+ return;
+ }
+ for (Map.Entry<Long, Integer> entry : priorities.entrySet()) {
+ if (entry.getValue() != null && entry.getValue() <
DeploymentPlan.DEFAULT_HOST_PRIORITY) {
Review Comment:
that covers it, comparing against the current host lets those vms move again
--
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]
