On 02/15/2016 08:18 PM, ramu wrote:
>
> 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 ?
The VLAN tag doesn't clearly identify a CIF. Consider this example:
logical port lp1
logical port lp1-1 with parent lp1, tag 100
logical port lp1-2 with parent lp1, tag 200
1) shutdown ovn-controller
2) swap tag on lp-1 and lp1-2
3) restart ovn-controller
This would result in the wrong zone IDs being used. It's probably also
a crazy example, though.
Another example to consider is the tag changing while ovn-controller is
running. It sounds like extra work to have to account for that.
I would use the name (ovn-zone-id-<name>), which is what we're already
using to tie Interface records to OVN.
> 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
Interesting thought. I think I have the same concerns about this as I
had for using ovn-zone-id-<tag>.
--
Russell Bryant
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
