hard anti-affinity for amphorae does not work

[garloff]

Talking to @maliblatt, I learnt that they had to tweak octavia to only use soft anti-affinity instead of hard anti-affinity in order to make loadbalancers spawn reliably. With hard anti-aff, they would otherwise not reliably succeed in finding two hosts (hypervisors) for the two amphorae.

I believe this should not happen. Assuming that the environment consists of more than a handful of hosts that can host amphorae, chances are very low that there is exactly one hypervisor with capacity for two amphora VMs but no two hypervisors can be found to fit in one amphora VM each.

For me, this raises a few questions:

• Do different LBs share server groups, so we don't deal with just a pair of amphorae but with many more? That would make the scheduler's job very hard, indeed. But why would you want to avoid amphorae from different LBs to land on the same host?
• Does the amphora scheduling go through the normal VM scheduler (placement service?) using normal server group anti-affinity like I also use as tenant user trying to create VMs? I have never seen issues even on gx-scs with finding 3 hosts for 3 control-plane nodes for a k8s cluster (where I use a server group with hard anti-aff).

The workaround is OK'ish (lowering the resilience of LBs a bit), so we have not a high urgency to analyze this. But something is wrong; maybe my limited understanding or maybe something in the way amphorae are scheduled.

[berendt]

• https://github.com/openstack/octavia/blob/master/octavia/compute/drivers/nova_driver.py#L277-L292
• https://github.com/openstack/octavia/blob/master/octavia/compute/drivers/nova_driver.py#L147

[Nils98Ar]

@berendt @garloff Do you know if it’s still needed to use soft-anti-affinity for octavia?

[berendt]

@Nils98Ar We are checking if this still occurs in Zed.

@matfechner Please take care of this.

[matfechner]

@berendt ok