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