15:00:41 #startmeeting Distributed_virtual_router 15:00:42 Meeting started Wed Apr 23 15:00:41 2014 UTC and is due to finish in 60 minutes. The chair is mrsmith. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:46 The meeting name has been set to 'distributed_virtual_router' 15:01:05 hi 15:01:20 xuhangp: hi 15:01:35 Swami wanted me to start the meeting, but he didn't give me an agenda 15:01:44 he said he will join ~8:20 15:02:01 #topic l3-agent WIP code posted 15:02:19 I posted my WIP code on monday for review 15:02:28 I've recieved a few comments - thank you 15:02:49 does anyone want to ask/comment on anything now? 15:03:07 let me add the link here - just a sec 15:03:37 l3-agent WIP code review: https://review.openstack.org/#/c/89413/ 15:03:53 #link https://review.openstack.org/#/c/89413/ 15:04:12 mrsmith: I will review the latest code today. 15:04:28 I had to remove some of the FIP support for DVR 15:04:37 since I was still mid merge/refactor 15:04:44 mostly just rules/tables related 15:05:01 but all of the top level logic is present 15:05:13 for namespaces, ports/interfaces, etc 15:05:21 no SNAT support yet 15:05:36 or rather "centralized SNAT for DVR" support 15:08:04 any other topics/issues people want to discuss before Swami joins us? 15:09:27 mrsmith: I know some people are interested to know when we will have enough code in gerrit for others to begin testing the whole solution. Can you give an update? What code has yet to be posted that is needed to run the whole solution? 15:10:17 good question carl_baldwin - we had E/W working on Havana 15:10:34 but porting to icehouse has made us do some refactoring 15:11:04 I think swami mentioned which milestone we are shooting for previously 15:11:23 so I will defer to him since I can't recall at this point - but I think it is early juno 15:11:39 juno-1. I’m not sure what the date will be. 15:12:53 as far as what code that is yet to be posted - it is mostly N/S related.... FIP and SNAT 15:13:08 both in the plugin/scheduler and agents (l2 and l3) 15:13:08 My best guess based on the Icehouse schedule is early June. 15:13:43 Could I (or another) successfully test E/W by pulling the code from gerrit? 15:14:06 possibly - I am new to this piece by piece posting 15:14:56 especially after the merges to top/master - we haven't tested all the pieces together yet 15:15:03 its really just WIP 15:15:29 Understood. 15:15:30 carl_baldwin: make sense? 15:15:34 :) 15:15:34 k 15:16:00 That was the sense that I was trying to get. 15:16:20 gotcha 15:16:49 With a goal of early June, we’ll want to be able to test the code in our own setups and confirm the functionality before it will merge. 15:17:01 understood 15:17:16 cool 15:19:01 hopefully swami will join us in a couple minutes 15:20:36 hi folks, sorry I am late 15:20:53 right on time! 8:20 15:20:59 hi Swami! 15:21:04 I need to rush through the traffic 15:21:10 hi Swami 15:21:13 mrsmith: Thanks for starting the meeting 15:21:14 so far we have been talking about l3-agent WIP code 15:21:24 Swami: no prob 15:21:33 sylvain: ping 15:21:42 Is sylvain in here 15:21:44 Swami, hi 15:21:48 carl_baldwin was asking about availability for testing 15:21:56 safchain: hi 15:22:23 carl_baldwin: Yes we will let you know when it will be available for testing. 15:22:36 Swami: great. 15:23:00 East-West should be functional. 15:23:18 But we are going through some more use case testing before we open it up to the upstream 15:24:03 In today's agenda I wanted to discuss the HA for the Service node and that's the reason I asked safchain to join the meeting 15:24:19 #topic DVR Serivce node HA 15:24:37 #topic HA for service node 15:25:25 safchain: We are currently planning to address the DVR service node HA by utilizing the HA VRRP patch that you have posted. 15:26:08 Since our agents are not going to change and we are planning to have only a single L3 Agent ( Enhanced), can we reuse the L3 VRRP patch that you have 15:27:13 Swami, I will split the current implementation of the agent, to extract the vrrp part in an external class 15:27:58 Swami, I need to understand how the service node will work 15:28:31 Service node currently hosts the Centralized SNAT service and the DHCP. 15:28:36 Swami, what will be the difference between the current l3 and the service agent node 15:28:49 Swami, ok so not floating ip 15:29:00 Yes no floating ip. 15:29:30 Swami, but finally it is just a matter of the dvr scheduler ? 15:29:31 The Service node will also host the L3 Agent but the L3 Agent will run in a SNAT mode. 15:30:15 Yes, there should be some intelligence in the scheduler to move the SNAT service between the service nodes. 15:31:31 But based on your current implementation, have you done any changes to the L3 Scheduler for the L3 VRRP. 15:32:05 Yes, a router is scheduled on severals agent 15:32:17 so there is a new scheduler for that 15:32:30 https://review.openstack.org/#/c/66347/ 15:33:37 safchain: Got it we might have follow the same scheduling model. 15:34:06 Swami, probably, I will review yours tomorrow 15:35:05 safchain: Our current L3 agent code does not have the SNAT support, but it will be worth if you could take a look at the L3 Agent code. 15:35:38 Swami, so when spawning a router, the new router will be scheduled on all compute node and on the service node, right ? 15:35:58 the l3-agent will rely on the host-id of the gateway port to decide if it will host SNAT 15:36:31 that would be the service node 15:36:37 Swami, sure I will take a look since it seems you already submit something around the scheduler 15:37:07 safchain: New routers will be spawned on all compute nodes. 15:37:33 Swami, and also and the service node ? right ? for the snat 15:37:56 Yes I wanted to confirm it with mrsmith 15:38:16 mrsmith: will the IR be created on the Service node or not? 15:39:26 yes 15:39:37 we are still in discussion if we need to create the IR on the service node or not. 15:39:37 safchain: is VPN part of the vrrp HA? 15:39:37 ideally it wouldn't do to resource usage 15:40:28 Rajeev, didn't check that yet 15:41:13 Swami, mrsmith it seems we have to use two different scheduler depending on the agent capabilities ? 15:42:14 safchain: why do you think that we need two different schedulers? 15:43:33 Swami, one to schedule a router on all compute node, and another one to schedule on severals service nodes ? 15:44:05 Swami, or one with two strategies which is almost the same thing 15:44:25 we were leaning to the two strategies model 15:44:35 one scheduler, two strategies 15:44:36 safchain: The second scheduler is specific to schedule the SNAT service 15:44:44 Swami, Safchain, we do have two scheduling activities, one to schedule the router(s) and the other to schedule the default SNAT capability 15:45:31 rajeev: Yes we are leaning towards the two strategy model 15:46:07 Rajeev, ok the default SNAT capability will be scheduled when a route will be created ? 15:46:29 Safchain: when an external gateway is set 15:46:45 safchain: Is there a specific requirement for the VRRP to have a separate scheduler? or can we handle it with the two strategy model. 15:47:49 Swami, I think you can implement the "dvr" scheduler on top of the vrrp scheduler 15:48:33 and call it when external gateway is set 15:48:38 safchain: This is to address the snat scheduling on different service nodes. 15:49:16 safchain: I will take a look at it again and I will also ask murali to take a look at it. 15:49:59 Swami, ok grat 15:50:01 great 15:50:41 safchain: rajeev raised a question about the VPN HA. 15:51:06 Swami, I have to take a look at it 15:51:10 Today VPN is tied to the L3 Agent and to the router, so theoretical it should not get affected. 15:51:31 Swami, yes should be but I will check that 15:51:35 But this will be just a HA for the router and not for the VPN service by itself. 15:51:47 Swami, correct 15:52:17 safchain: Thanks for your input on the vrrp. 15:52:33 Swami, thx, don't hesitate to ping 15:52:46 #topic Gerrit-push-with-dependency 15:52:59 general question, is there a limit on number of subnets attached to a router ? 15:53:11 #topic Gerrit-push-with-dependency 15:53:24 Rajeev: I don’t know of any limit. 15:53:27 I am pseudo swami today :) 15:53:40 Rajeev: Neither subnets nor networks. 15:53:57 carl: thx. 15:54:46 carl: I have question on the dependencies for the gerrit push 15:55:06 I knew that was coming. :) 15:55:22 The gerrit workflow states that we need to "git review -d $PARENT_CHANGE_NUMBER" 15:55:51 What is the PARENT_CHANE_NUMBER? 15:56:02 Is this the change id in the gerrit. 15:56:06 It is the 5 digit number at the end of the URL. 15:57:20 The 5 digit number identifies a change id on a particular branch. Since change ids can be reused across branches, the change number uniquely identifies the (change id, branch) tuple. 15:57:21 So the process is first, do a "clone" of the master repo. 15:57:43 Then fetch the dependency patch. 15:58:11 And then should we run the "git review -d $Parent_change_number" command 15:59:31 Swami, the git review -d is just to checkout the review 15:59:37 I think so. And then rebase the “parent” to the dependency. 16:00:08 running low on time folks 16:00:22 Swami - time to wrap up? 16:00:31 ok, thanks folks 16:00:33 We can move the discussion to the neutron room if you still need some guidance. 16:00:38 sylvain: carl: thanks. 16:00:50 I will check with you later if I have any other issues. 16:00:53 Now it is clear. 16:01:07 Thanks for joining the meeting. 16:01:09 Swami: ML2 meeting time…:-) 16:01:11 See you all next week. 16:01:12 bye 16:01:14 #endmeeting