Thanks a lot Han! Great and swift work! I'm testing them now, will let you know ASAP.
On Thu, Mar 1, 2018 at 8:39 AM, Han Zhou <zhou...@gmail.com> wrote: > > > On Mon, Feb 26, 2018 at 12:05 PM, Ben Pfaff <b...@ovn.org> wrote: > > > > On Fri, Feb 23, 2018 at 03:51:28PM -0800, Han Zhou wrote: > > > On Fri, Feb 23, 2018 at 2:17 PM, Ben Pfaff <b...@ovn.org> wrote: > > > > > > > > On Tue, Feb 20, 2018 at 08:56:42AM -0800, Han Zhou wrote: > > > > > On Tue, Feb 20, 2018 at 8:15 AM, Ben Pfaff <b...@ovn.org> wrote: > > > > > > > > > > > > On Mon, Feb 19, 2018 at 11:33:11AM +0100, Daniel Alvarez Sanchez > > > wrote: > > > > > > > @Han, I can try rebase the patch if you want but that was > > > > > > > basically renaming the Address_Set table and from Ben's > > > > > > > comment, it may be better to keep the name. Not sure, > > > > > > > however, how we can proceed to address Lucas' points in > > > > > > > this thread. > > > > > > > > > > > > I wouldn't rename the table. It sounds like the priority should > be to > > > > > > add support for sets of port names. I thought that there was > already > > > a > > > > > > patch for that to be rebased, but maybe I misunderstood. > > > > > > > > > > I feel it is better to add a new table for port group explicitly, > and > > > the > > > > > column type can be a set of weak reference to Logical_Switch_Port. > > > > > The benefits are: > > > > > - Better data integrity: deleting a lport automatically deletes > from the > > > > > port group > > > > > - No confusion about the type of records in a single table > > > > > - Existing Address_Set mechanism will continue to be supported > without > > > any > > > > > change > > > > > - Furthermore, the race condition issue brought up by Lucas can be > > > solved > > > > > by supporting port-group in IP address match condition in > > > ovn-controller, > > > > > so that all addresses in the lports are used just like how > AddressSet is > > > > > used today. And there is no need for Neutron networking-ovn to use > > > > > AddressSet any more. Since addresses are deduced from lports, the > > > ordering > > > > > of deleting/adding doesn't matter any more. > > > > > > > > > > How does this sound? > > > > > > > > Will we want sets of Logical_Router_Ports later? > > > At least I don't see any use case in Neutron for router ports since > > > Security Group is only for VIF ports. > > > > > > There is another tricky point I see while working on implementation. In > > > Neutron, SG can be applied to ports across different networks, but in > OVN > > > lports works only on its own datapath, so in ovn-controller we need to > be > > > able to pickup related ports from the port-group when translating > lflows > > > for each datapath. I hope this is not an issue. Otherwise, Neutron > plugin > > > will have to divide the group of ports into sub-groups according to the > > > lswitch they belong to, which would be a pain. > > > > I think that we can make ovn-controller gracefully tolerate that. > > > > Let's try this implementation. I'm not excited about having a new table > > for this purpose, but it sounds like the advantages may be worthwhile. > > Here are the patches: https://patchwork.ozlabs.org/ > project/openvswitch/list/?series=31165 > > Thanks, > Han > >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss