09:00:26 #startmeeting Dragonflow 09:00:27 Meeting started Mon May 22 09:00:26 2017 UTC and is due to finish in 60 minutes. The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:30 The meeting name has been set to 'dragonflow' 09:00:31 Hey 09:00:34 Hello. Who's here for the Dragonflow weekly? 09:00:36 Hi 09:00:57 Tough croud 09:01:04 crowd* 09:01:49 nick-ma, hi 09:02:11 hi 09:02:14 #info lihi dimak_ nick-ma in meeting 09:02:17 Let's begin 09:02:22 #topic Roadmap 09:02:29 IPv6 - lihi ? 09:03:24 I planned to update a patch by now, but I'm still rebasing it. Will upload today 09:04:17 All right. Just reminder - portsec is the last patch for the bp, right? 09:04:23 https://review.openstack.org/#/c/464569/ 09:04:25 Yes 09:04:32 Great! Thanks! 09:04:46 Chassis health - patch was merged! 09:04:56 🎊 09:04:57 Woohoo 09:05:11 :) 09:05:34 Northbound API - lport finally passes gate 09:05:48 🎊🎊🎊 09:06:07 Also most votes are positive. I hope it will make it in soon 09:06:19 I hope this will be the last time I have a ~1400 line patch :) 09:06:39 lport migration patch: https://review.openstack.org/#/c/447366/ 09:06:42 #link lport migration patch https://review.openstack.org/#/c/447366/ 09:07:06 I am now working on VLAN aware VMs on top of it. I hope to have it done by Wednesday. 09:07:13 That leaves us with SFC - dimak_ ? 09:07:47 I've rebased it on top of the passing lport patch and bringing up a machine to see if it still works :P 09:08:01 I still have some -1 from you on a patch with 09:08:12 "Requires further discussion" 09:08:19 The further discussion didn't follow 09:08:31 dimak_, which patch? I don't remember what needs to be discussed 09:08:44 It's the one that split several OVS tables 09:08:52 To allow classification 09:09:07 We can do it with regs, just need to decide how we do it 09:09:08 This one: [04/xx] Split L2 and egress tables ( https://review.openstack.org/#/c/429666 ) ? 09:09:13 Yeah 09:10:03 All right - the discussion is that this patch splits the L2 table into two tables 09:10:15 To allow SFC to inject flows in the middle 09:10:50 I think this is redundant - that SFC can inject its flows in the L2 table with a higher priority. dimak_ disagrees. dimak_ - does this sum it up correctly? 09:11:02 Yes 09:11:09 Once the packet is out of SFC 09:11:14 it goes again to L2 table 09:11:20 and gets classified again 09:11:47 We have to mark it in some way that it did the SFC part already 09:12:06 (Splitting tables was your suggestion btw :P) 09:12:26 What's the reg6 value (source lport)? The first time round, is it the source VM? The second time round, what is its value? 09:12:54 (Many of my solutions appear to be... bad... Apparently (:. Sorry for the red herring) 09:13:18 It depends whether we intercept on source port or on dest port 09:13:43 but if I am restoring a source port classification, I restore reg6 aswell 09:13:54 as well 09:14:09 And if you don't, reg6 is empty? Or the SF's lport? 09:15:10 Could be empty, could be SF 09:15:20 In a multinode env its a problem 09:15:35 Last SF can be on other machine than dest 09:16:04 But then L2 is done on the other machine, no? 09:16:23 On the SF's node, that is 09:16:25 ? 09:16:39 We can decide we terminate the SFC on the machine it was classified at 09:17:03 It's a bit redundant but that way you can know for certain to not classify it again 09:18:15 Lets discuss it on the patch 09:18:20 Wait, how do you know now that the chain has finished and to proceed to destination? What if the chain is longer? 09:18:25 Sure 09:18:54 That's actually it for roadmap 09:19:15 I hope that next week we will have made some headway in VLAN aware VMs and SFC, and we can discuss future directions 09:19:30 +1 09:19:34 Anything else for roadmap? 09:20:06 #topic Bugs 09:20:26 I want to stop here and give a big thank you for nick-ma for the excellent work during the bug smash last week! 09:20:51 thanks your assignment. :-) 09:21:36 I want to discuss bug 1691904 for a minute. 09:21:38 bug 1691904 in DragonFlow "an object is deleted twice that causes object not found" [Critical,New] https://launchpad.net/bugs/1691904 09:21:48 yes, i found it in the ci. 09:22:04 As I wrote on the bug, I think https://review.openstack.org/#/c/466149 should close this bug. 09:22:31 Some investigation shows that Topology sends the same events as received from the neutron server 09:22:52 ok. if it is the case, i think we just ignore it. 09:23:03 Sounds good. 09:23:11 i will update the commit msg. 09:23:14 to close it. 09:23:21 Great. Thanks again! 09:23:32 Anything else for bugs? 09:24:04 #topic Open Discussion 09:24:32 The floor is for the taking 09:25:11 All right then. 09:25:20 Thanks everyone for coming. 09:25:26 Bye 09:25:34 #endmeeting