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