This BZ is related to the work done in https://bugzilla.redhat.com/show_bug.cgi?id=1849571

The ML2/OVN driver now supports router availability zones but, when configuring the AZs the ML2/OVN differs from ML2/OVS as it does not use the same configuration options to do so.

This was not by choice since ML2/OVN does not have agents (L3 agent more specially for this case) therefore there's no configuration files to set the availability zones to. In that case, ML2/OVN uses the local OVSDB for this.

This is done via the ovn-cms-options entry in external_ids column of the local Open_vSwitch table, e.g:

$ ovs-vsctl set Open_vSwitch . external-ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0:az-1:az-2"

Or, in the TripleO-Heat-Templates language this is the equivalent of setting the "OVNCMSOptions" configuration in the template as:

OVNCMSOptions: "enable-chassis-as-gw,availability-zones=az-0:az-1:az-2"

As you can see, this is just a string and we've heard some complains about it not being user-friendly. So this BZ is about this usability issue that we have in setting the availability zones for OVN using TripleO-Heat-Templates.

Ideally, it would be good to have a separated key in the template that holds a list (e.g OVNAvailabilityZones [0]) and underneath THT would create the string and append to the value of the "OVNCMSOptions" options. For example:

OVNAvailabilityZone: ['az-0', 'az-1', 'az-2']
OVNCMSOptions: "enable-chassis-as-gw"

That would result in ovn-cms-options="enable-chassis-as-gw,availability-zones=az-0:az-1:az-2" being set in the local OVSDB.

[0] I would also suggest to keep the name generic and not add Router to it even if this BZ is about router availability zones. Reason being, OVN will use this same settings to also add Network Availability Zones in the future. So the same configuration will apply to both.