On Tue, Mar 1, 2016 at 11:27 PM, Darrell Ball <db...@vmware.com> wrote:
> Hi Mickey > > I was going with the assumption that the “localnet” logical port on each > HV has a unique name linked to HV/logical switch tuple > Localnet configuration uses multiple logical switches to support a single > localnet. > > My reference to base this assumption on was this link > http://openvswitch.org/pipermail/git/2015-September/007480.html > This changed within the last week. Sorry. :-) https://github.com/openvswitch/ovs/commit/6e6c3f9188a19d4e8981eb7813dd87fa54b8e882 We worked out an acceptable way to model connectivity to a localnet with a single logical switch. > Also, if you check the OVN tests for localnet, the configuration uses the > same approach. > Oops. This should have been changed when the above patch merged. Han, is this something you could look at doing? > If this assumption holds, then even for localnet, a logical port is only > bound to a single physical endpoint (chassis/port/encap) > > I think you are suggesting that a single logical port name for a localnet > network be used across the HVs ? > > Then the logical port becomes a single name, such as your example below - > provnet1-physnet1 > > I understand the advantage of a using a single logical port name in some > cases, as it slightly simplifies the configuration at the NB, > > although we would still need to configure each HV access point uniquely with > ovs-vsctl for physical endpoints then. > > > However, in general, I think there may be some reasons to retain the unique > logical port names for localnet access points - > > to support different addresses and port security per logical access point, > per the NB schema. > > > Let me know if you think being able to have a single localnet logical port > name across > > hypervisors is a hard requirement. > > It is, based on the current state of the code. It helped simplify the OpenStack Neutron plugin a lot. It also drastically reduces the number of logical flows needed to model many ports connected to a localnet. > I think the explicit bridge-mapping for localnet could be eliminated. > > The network_name is associated with a logical port and a > > logical port is bound to a physical endpoint chassis, which is the > > localnet access bridge…. > > However, I did not mention it in this patch, because for localnet, > > I just wanted to focus on the encapsulation/tag for now. > > Yes, I think moving the bridge mappings info into southbound is a nice improvement. We've come across a case where we need to know this information in our OpenStack Neutron plugin, so I was hoping that we'd be able to read it from the southbound database as a nice side effect of this work. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
