15:02:29 #startmeeting distributed_virtual_router 15:02:30 Meeting started Wed Apr 16 15:02:29 2014 UTC and is due to finish in 60 minutes. The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:33 The meeting name has been set to 'distributed_virtual_router' 15:02:42 swami: hi 15:02:46 #topic Agenda 15:02:58 1. DVR Progress 15:03:13 2. Gerrit review update 15:03:25 3. L3 Agent Update 15:03:30 4. L2 Agent Update 15:03:42 5. L3 Driver update 15:03:53 #topic DVR Progress 15:04:45 DVR work is in Progress. East-West is done. We are almost done with the FIP work. 15:05:00 Swami: time permitting, suggest poll for topics of interest at summit 15:05:00 FIP work not complete yet. 15:05:26 rajeev: thanks 15:05:56 SNAT work will be taken once we finish the FIP work. 15:06:38 Last week we gave an update to the Neutron PTL on the DVR Progress to align with the Juno milestones 15:07:04 The target is to push all the code before the summit to the gerrit for review. 15:07:20 Our target will be Juno milestone 1 15:08:06 We wanted to have some testable code in there by Juno milestone 1, so that enough testing will be done to test for stability. 15:08:53 Also the discussion that I had with the PTL includes redefining the test infrastructure to have multinode setup to accomodate the DVR test. 15:09:14 Hope this helps. 15:09:32 #topic Gerrit review update 15:09:49 The Plugin code and the L2 Agent code is now in gerrit for review. 15:10:06 #link https://review.openstack.org/84223 15:10:16 L2 Agent code 15:10:33 #link https://review.openstack.org/87730 15:11:07 Thanks for the early review comments on the patch posted. 15:11:31 Still there are couple of more patches that we will be pushing in the next week. 15:11:50 L3 Scheduler code, L3 Agent code and L3 Drivers. 15:12:53 Swami: I find this link to be useful to watch all of the commits: 15:12:54 #topic L3 Agent 15:12:55 #link https://review.openstack.org/#/q/topic:bp/neutron-ovs-dvr,n,z 15:13:21 carl: thanks for posting the link 15:13:34 mrsmith: can you give an update on the L3 agent 15:13:47 Swami: yes 15:14:01 initial merge to icehouse-2 is done 15:14:14 I am trying to cleanup/resolve the FIP conflicts 15:14:30 I may end up pushing a subset of the functionality for review 15:14:36 just for clarity 15:14:53 but I should be able to push something by next wed 15:15:16 the refactoring/changes occuring in the FIP area has resulted in more changes for DVR 15:15:53 mrsmith: Thanks for your update. 15:16:00 np 15:16:14 vivek:ping 15:16:37 #topic L3 Drivers 15:16:52 Rajeev where are we with respect to the drivers 15:17:33 is rajeev in here. 15:17:43 did we lose him 15:17:49 hmm.. he was there 15:17:50 swami: all our changes are in the L-3 agent itself 15:17:57 that's fine. 15:18:09 rajeev: here he is. 15:18:11 Rajeev: including the change to ip_lib.py? 15:18:18 want me to push that as well? 15:18:46 there are a few pieces in ip_lib that I will push it in 15:19:01 during this week 15:19:03 rajeev: mrsmith: thanks 15:19:13 sounds good. 15:19:53 #topic FIP Gateway issue 15:20:19 There was one question that came up in our discussion regarding the FIP behavior today in openstack neutron. 15:20:56 So we need the community opinion on this before we proceed. 15:21:34 Today in a Centralized router mode, when a FIP is assigned to a VM, any incoming traffic from an External Network uses the FIP IP as the destination IP and the traffic flows to the VM. 15:21:57 When the VM responds to the request the traffic also passes through the FIP. 15:23:04 But for any normal traffic that initiates from the VM, it uses the default gateway configured in the VM and the traffic flows through the SNAT. 15:23:41 When we implement the North-South in a distributed DVR, the Floating IP will not be on the same node as the SNAT and so how do we want this behavior to be. 15:23:43 Swami, for a VM with an associated floating ip that should not be true. 15:24:07 swami: I agree with Carl, same opinion 15:24:15 Outgoing traffic will always prefer the tip as source ip and not default SNAT address. 15:24:30 s/tip/fip/ 15:24:57 carl: rajeev: Yesterday I heard this from our internal folks. I can re-confirm this. 15:25:07 when FIP in place, rules don't allow default SNATing 15:25:17 I am not sure if murali or vivek is in this meeting. 15:25:47 swami: np, we can take it offline. 15:25:47 rajeev: carl: thanks for the update. 15:26:00 I'm pretty confident that the iptables rules in the router are structured to alway s source traffic from a fip when associated. 15:26:16 Let me know if you need more technical clarification for your follow-up. 15:26:50 Ok, so the agreement here is whatever is the behavior today in Openstack we will follow the same model. 15:27:06 Agreed. Any other behavior is a bug. 15:27:16 Irrespective of centralized or distributed for the FIP> 15:27:27 Right. 15:27:38 If I have more information on this "bug", then I will bring it up in the next meeting. 15:28:36 yes, i would agree with carl, fip is preferred 15:29:00 haleyb: Thanks for confirming it brian. 15:30:21 #topic DVR HowTo wiki 15:31:08 For the Neutron Documentation team to get started we are planning to include a "DVR HowTo", so that it would be helpful for the folks who are testing and as well as for the documentation folks. 15:31:34 So we will be updating the DVR HowTo wiki on more information. 15:32:12 #link https://wiki.openstack.org/wiki/Neutron/DVR/HowTo 15:32:26 This is just a template and we will add more content as we progress. 15:32:31 Swami, that will be really helpful for us to test it too! 15:32:50 xuhanp: Yes this is to enable testers. 15:33:26 viveknarashimhan: hi 15:33:40 #topic L2 Agent Update 15:34:27 vivek: are you there. 15:34:31 hi 15:34:48 i am there 15:35:34 viveknarasimhan: can you provide an update for the L2 agent 15:35:54 i posted the L2 Agent/ML2 plugin WIP code for review 15:36:05 i have been getting review comments from lot of folks 15:36:20 i will be starting to address them one-by-one from today 15:36:35 The port-binding changes are done and i am running various type of use-cases on it 15:37:01 like DVR hosted + Non DVR hosted VM type of cases to make sure old behaviour didn't brek 15:37:27 i have a question though 15:37:50 i we link the patches say L3 Extension patch is linked with my L2 patch put for review 15:38:19 if i do git pull --rebase, then will I be required to address conflicts i nthe L3 Extension patch also? 15:38:43 so the question is: when patches are linked, how is git pull --rebase handled , before we repost for review 15:39:35 viveknarasimhan: no I am not an expert in this area. 15:39:51 I can check offline and let you know. 15:39:55 viveknarasimhan: which patch? 15:40:27 amotoki: Viveknarasimhan has a dependency of the L3 extension patch that we posted for review. 15:41:09 Swami: I just check the exact one. I am looking for it in the review list... 15:41:18 So he is asking how to post patches that have dependencies for review and if the dependent source tree has any conflicts, how to resolve it. 15:41:24 this patch: https://review.openstack.org/87730 15:41:45 the above patch is the L2 side changes and this dependes on L3 side changes also posted by Swami earlier 15:42:20 I got it. I think if there is no direct dependency you can post without dependency (if there is a note in the commit message). 15:42:38 amotoki: There are the two patches 15:42:41 #link https://review.openstack.org/#/q/topic:bp/neutron-ovs-dvr,n,z 15:43:26 yes i know. perhaps you are talking about how to manage the dependency. 15:43:35 amotoki: Thanks for your help. 15:43:49 viveknarasimhan: We can take it offline and resolve this issue. 15:43:52 if you have a question, i can help anytime. 15:44:02 i will mail you amotoki 15:44:09 amotoki: Thanks for your help again. 15:44:17 i will also CC mestery on the same question. Thanks for your help amotoki. 15:44:44 #topic FIP/SNAT question. 15:44:59 There was another question that we had with the FIP/SNAT. 15:45:24 Today in the distributed model, we will be having SNAT and FIP running on two different nodes. 15:46:28 When an admin removes the "SNAT" binding from an agent, then should FIP still continue to work?? this is the question 15:48:39 Any suggestions? 15:48:57 Swami: FIP and SNAT are independent 15:49:05 so should continue to work 15:49:07 I can help with the patch dependency issue as well. 15:49:20 rajeev: Yes thanks for your input. 15:49:27 An external gateway has to be set for the router 15:49:28 Swami, what do you mean by "remove the binding"? 15:49:31 but don't we require the external-gateway-set? 15:49:35 * pcm__ On dependency: https://wiki.openstack.org/wiki/Gerrit_Workflow#Add_dependency 15:49:36 for FIP? 15:49:39 Thereafter both SNAT and FIP can be there 15:50:14 Even though FIP and SNAT are different mrsmith mentioned there is some dependency and so we wanted to get broader consensus on this before we proceed. 15:50:16 From an agent perspective, it can handle SNAT in addition to FIP depending on what it's .ini says 15:51:06 in this case in FIP namespace what is gatway IP? 15:51:09 seems awkward to me to require ext-gw-set, but then allow it to be cleared 15:51:17 xuhanp: We are proposing an admin level command to remove and add SNAT from an agent. 15:51:19 for FIPs 15:51:43 xuhanp: That is what I mentioned as binding to the agent. 15:51:53 Swami, you mean choose another agent to take the SNAT role node? 15:52:22 xuhanp: Yes, before you move, you first remove the binding from the current SNAT agent. 15:52:39 Swami, thanks for the clarification 15:53:04 mestery: Thanks for your help. 15:53:51 So what i am hearing is in the distributed model, SNAT behavior should not affect the FIP. 15:54:04 or vise versa. 15:54:44 mrsmith: Do you have any suggestions on this or do you want to discuss this more next week. 15:55:32 I'll admit I don't completely understand what the dependency between FIP and default SNAT might be. 15:55:32 it is possible to do, and I guess a "good" feature to be able to move SNAT while FIPs are running 15:55:36 Ok, let us talk about this topic more indepth in the next meeting. 15:55:43 sure 15:56:01 the only dependency is in the current code 15:56:05 more to refactor 15:56:15 So, an implementation level dependency. 15:56:20 yes 15:56:27 We only have a couple of more minutes. 15:56:36 #topic General discussion 15:56:40 I see. I think we can work that out. I've done some work with this as well. 15:56:45 Does anyone have any other topic to discuss. 15:56:52 carl: sounds good 15:57:13 I knew that rajeev brought up some summit design discussion topic. 15:57:13 For the summit, we want to poll audience on future for DVR 15:57:45 Rajeev, we do have signed up for a "DVR update". 15:58:07 In order to achieve partiy with Nova, we also need to complete the Distributed DHCP. 15:58:13 Great 15:58:33 This is one of the major topic that came up last week when I discussed DVR with Mark McClain. 15:58:46 I just started off 15:58:51 with the Distributed DHCP document 15:59:00 So the immediate need is "refactor' the L3 Agent/L2 Agent code and also to support Distributed DHCP. 15:59:03 i will whet that with you Swami and then we can proceed from that point 15:59:26 Ok we are almost at the end of the hour 15:59:42 Thanks all for joining this meeting. 16:00:01 Keep up the momentum. 16:00:08 bye 16:00:13 #endmeeting