Comment 2 for bug 2030741

Hello Rodolpho Alonso:

Thanks a lot for your returns.

By "Failure domains", I meant an equipment group (server, network hardware, power supply, etc...) that could be lost for any reason without affecting the other groups and consequently the service globally.

For example, our openstack nodes are distributed over multiple rooms in a datacenter. So that, in each room, we have some of our network-dedicated nodes. From this point of view, each room could be considered as a "failure domain". The goal is to have an automatic failover in case of any failure affecting one single room.

Until now, we used ML2/OVS. Nodes from room 1 were placed in the same AZ az-1, nodes from room2 in az-2... Using l3_ha mode and AZ aware schedulers we had router instances spawned on each of these AZs, so that we could lose any single zone without affecting the service (after vrrp timers of course).

For different reasons, we’d like to use OVN in the near future (and do the same). Out of the box, in our use case, using ML2/OVN, that should be OK until having no more than 5 * number of AZs network nodes. But, that may not be sufficient for us in the future as we already use slightly more.

Disabling or removing nodes should be feasible (even temporarily) but it won’t be automatic.

As you suggested, to deal with that and still use OVN, we wrote a little patch to add two new schedulers that optionally reorder the list taking care of AZs… and that works !

I share with you a refreshed version of this patch for trunk (we work on a previous version of openstack neutron that needs some other back-ports for that to work). The only draw-back is the need to call get_chassis_and_azs from sb_idl and therefore propagating it (again) along scheduler functions.

Please let me know if you have any questions.

Regards.