> > > Unfortunately, I thought of another issue that complicates this whole > approach. A single interface does not necessarily map to a single > logical port and zone ID. We support sub-ports, initially aimed at > modelling containers in VMs. That means we need to track N different > zone IDs on a single interface record. For more info, see "Life Cycle > of a Container Interface Inside a VM" in ovn-archtecture(7). > > For that use case, we could easily have many hundreds of sub-ports using > a single interface. Maybe we should have external-id keys of the form > "ovn-zone-id-<name>" where <name> is the logical port the zone id is > for? We'd need some additional code for cleaning up zone IDs for > sub-ports that have been deleted. >
Thanks, In the case of a cif, can we have the key as: ovn-zone-id-<tag> where the tag is the vlan which distinguishes the cif on the vif ? But, this will result in external id containings lots of keys - would that be acceptable ? An alternative approach just for comparison is: during ovn-controller startup to look at the installed flows in table 0 of the flow table, and recover the zone-id -> (ofport, tag) map and from there deduce the logical-port -> zone-id map _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
