15:01:35 #startmeeting distributed_virtual_router 15:01:35 Meeting started Wed Aug 6 15:01:35 2014 UTC and is due to finish in 60 minutes. The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:39 The meeting name has been set to 'distributed_virtual_router' 15:01:46 Vinod_: hi 15:01:53 pcm_: hi 15:01:56 #swami Hi 15:02:03 Bhooshan: hi 15:02:36 howdy all 15:02:52 #info Juno 3 Milestone 15:02:59 mrsmith: hi 15:03:17 Juno 3 milestone cut of date is August 21st. 15:03:47 So all our code should probably end up as upstream patch for review by next week. 15:04:17 #topic DVR status update 15:04:53 As you all might know most of our patches have landed upstream and we are currently testing the DVR. 15:06:04 carl_baldwin:hi 15:06:19 Swami: hi, apologies for being late 15:06:27 carl_baldwin:np 15:06:57 Swami: Is there a list anywhere of what all is being tested, as far as features / functionality is concerned? 15:07:42 sld: The DVR Howto will provide you instructions on how to install, configure and test the DVR 15:08:05 #link https://wiki.openstack.org/wiki/Neutron/DVR/HowTo 15:08:14 thanks 15:08:21 But we don't have a list of test cases that we are testing. 15:08:42 But as we test when we see a bug or an issue we are filing the bugs in luanchpad. 15:08:48 gotcha. 15:08:56 *luanchpad Launchpad 15:09:29 sld: the bugs are all here, https://bugs.launchpad.net/neutron/+bugs?field.tag=l3-dvr-backlog 15:09:47 haleyb: Thanks for the link 15:10:04 #topic DVR Horizon 15:10:23 Bhooshan: can you give an update on where we are with the Horizon work for DVR 15:10:41 I have started implementing Horizon UI change for DVR support 15:11:10 Planning to upload the first patch by this weekend 15:11:30 Bhooshan: I knew that you have some mock up screens 15:11:50 yes, do I need to post it on white board 15:12:41 Its ok, next time if we want to go through the screens,please upload it to the Google drive and we can all see the screens 15:12:54 Horizon UI part almost completed 15:13:00 sure I will do that 15:13:35 Bhooshan: If you have the screen shots already done as part of the Horizon, and even if it is not fully functional, you can upload as "WIP" for internal review. 15:13:56 ok 15:14:01 Bhooshan: you don't need to wait till the end of the week for this. 15:14:22 sure, I will do that next time 15:15:26 Bhooshan: Also you had some questions on how to handle the user level previleges in Horizon. Check with Amotoki on this and then start your implementation. 15:16:16 Bhooshan: Thanks for your update. 15:16:30 #topic Bugs 15:16:46 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=l3-dvr-backlog 15:18:27 The link posted above provides the status of the all the bugs that are related to the dvr. Also for tracking purpose we have included the backlog items as part of the buglist 15:18:47 How is bug 1350485 looking? 15:18:48 Launchpad bug 1350485 in neutron "Fix L2Pop mech driver for dvr to handle DVR interface ports" [High,In progress] https://launchpad.net/bugs/1350485 15:19:56 viveknarashimhan: Any updates on the bug 15:20:37 Looks like the fix has failed Jenkins. 15:20:38 As per the discussion yesterday he seems to have patch and armax was testing it. 15:20:45 i posted the review 15:21:03 i am not sure why tes_l3_plugin fails in jenkins for the posted patch, 15:21:16 as i didn't touch anything in test_l3_plugin 15:21:43 would help if team here could give insight . here is the review link: https://review.openstack.org/#/c/112229/4 15:22:25 viveknarasimhan: Just make sure if any rebase caused this issue. 15:22:31 my local runs for test_l3_plugin works fine though 15:23:31 viveknarasimhan: I will take a look at it. 15:24:12 carl_baldwin: any update on #link https://bugs.launchpad.net/neutron/+bug/1348306 15:24:14 Launchpad bug 1348306 in neutron "L3 agent restart disrupts fip namespace causing connectivity loss" [High,In progress] 15:24:40 I believe the fix is ready to merge. 15:25:00 carl_baldwin: thanks 15:25:05 yw 15:25:25 We’ll just give it a little time for more reviews. 15:25:46 #link https://bugs.launchpad.net/neutron/+bug/1352801 15:25:48 Launchpad bug 1352801 in neutron "l2pop to stop using tuples everywhere" [High,In progress] 15:26:00 carl_baldwin: any update on the 1352801 15:26:17 bug 15:26:28 bug 1352801 15:26:29 Launchpad bug 1352801 in neutron "l2pop to stop using tuples everywhere" [High,In progress] https://launchpad.net/bugs/1352801 15:26:32 carl_baldwin: yes 15:26:47 * carl_baldwin just wanted uvirtbot to give me a link 15:26:54 still in progress 15:26:59 Will wrap it up today. 15:27:28 viveknarasimhan: Any update on the VM fails to get IP address #link https://bugs.launchpad.net/neutron/+bug/1352857 15:27:30 Launchpad bug 1352857 in neutron "few VMs fail to get ip address in devstack" [High,In progress] 15:27:42 teh fix is same as posted for 1350485 15:27:58 so i put in commit msg both the bugs as Closes-Bug attribute 15:28:00 Stephen confirmed that. 15:28:16 Ok so they both are related. 15:28:30 carl_baldwin: ok thanks, I got it. 15:28:33 Yes, for both root cause is the same 15:29:08 good 15:29:42 mrsmith: I think the next bug marked as "high" is owned by you. 15:30:06 I think this has just comein last night 15:30:35 I just grabbed that one 15:30:44 about re-allocating FIPs 15:30:54 I'll focus on that today 15:31:09 So I think we are all working on the high's right now and most of other bugs are either in Fix-commited or In-progress. 15:31:50 There was one bug related to "enable_snat=False" should not create a SNAT namespace. 15:32:35 #link https://bugs.launchpad.net/neutron/+bug/1352798 15:32:36 Launchpad bug 1352798 in neutron "when a external network is attached to the router with disable-snat no snat namespace should be created " [Medium,New] 15:32:58 I did verify and this is valid bug. 15:33:08 theres a couple in that area 15:33:17 I am guessing it is a scheduling issue but not sure 15:33:24 I think I have one of them and armax has the other 15:33:42 area = snat_enable 15:34:09 msrmith: carl_baldwin: I have some questions around this "enable_snat=true/false", right now with the legacy routers I see an issue with these flags not propoerly handled. 15:34:45 Swami: what is the question? 15:34:48 either i set the flag to true or false, the legacy router namespace has a rule for SNAT 15:35:22 Swami: Hmmm. That sounds like a bug. 15:35:27 right 15:35:50 mrsmith: In a legacy router today when you create a gateway with enable_snat=true and then if you change enable_snat=false, the iptables rules inside the namespace does not change. 15:36:12 when you say "today" that is current juno 15:36:21 are you asking about what was from before? 15:36:25 Yes it was yesterday's pull 15:37:12 ok, we can discuss this offline and see if this a bug even in the case of legacy routers. 15:38:07 Let us move on to the backlog items 15:38:15 #topic backlog items 15:38:23 #topic migration 15:38:49 We just pushed in another patch for the migration. 15:39:20 The migration work is in progress. 15:39:43 mrsmith: do yu have any input on the migration 15:40:34 carl_baldwin: I do have some questions related to migration and the CLI commands that are available today for manual agent binding 15:40:55 Swami: go 15:41:58 Yes today the CLI command for either moving a router from one 'L3" agent to another has a single command. 15:42:39 "l3_agent_router_add' and "l3_agent_router_remove". 15:43:05 In our case we do have two l3_agents running in two different modes either "dvr_snat" or "dvr". 15:43:42 These commands are relevant only in the dvr_snat case, right? 15:43:55 So how do we re-use the same existing CLI commands and move or migrate the routers to the respective agent. 15:44:35 carl_baldwin: That is my question, in our case these will be only applicable for snat service and not for a regular router service. 15:44:43 Right. 15:45:29 The associated of a distributed router to a dvr_snat agent is very much like the association of a legacy router to a legacy (or dvr_snat) agent. 15:45:38 Do we then need to document saying that 'l3_agent_router_add" and "l3_agent_router_remove" for dvr will be only applicable for snat service. 15:46:11 Swami: adding to the documentation that the commands are relevant only to the snat part of the router would be good. 15:46:28 ok. 15:47:14 Also in this case, if the command is issued accidentally to a wrong agent that is not configured for "dvr_snat", should we raise an error message or do nothing if the router is DVR. 15:47:52 Swami: I think an exception should be raised. 15:48:17 Ok, got it. 15:48:40 mrsmith: Do you have any questions on this 15:49:17 Swami: no - is this how we are going to handle snat manual scheduling in general? 15:49:30 I agree with the above 15:49:53 I think this is the route we are headed. 15:50:06 ok 15:50:20 So we will not introducing additional CLI commands just for the SNAT and re-use the existing commands. 15:50:59 But we need to raise an exception for those commands based on the agent type. 15:51:27 #topic Services 15:51:40 pcm_: are you there 15:52:14 sridhark: ping 15:52:45 they might have dropped off. 15:53:00 yes 15:53:28 I will check with FWaaS team on their progress to support DVR enabled routers. Based on monday's status they mentioned that they are progressing on their work. 15:53:34 pcm_:hi 15:53:54 I just want to touch base with you on the VPNaaS support for the DVR 15:54:55 ok. Just back from a week of vacation... not sure what plans are for that. 15:55:07 As of now we need make sure that when we assign a router to a VPNaaS, we need to make sure if that router is distributed or not, if distributed we might have to through a "NotImplementedError". 15:55:48 pcm_: please let me know your thoughts on this. 15:56:19 We can have a discussion offline on this. 15:56:32 yeah would be good. 15:57:25 For the LBaaS we are currently testing different use cases with the DVR to make sure that nothing has broken. But any volunteers to test LBaaS would be very helpful. 15:57:49 #topic OpenDiscussion 15:58:38 Armax mentioned today that the experimental job for DVR to run scenario tests is have some issue. So any volunteers can help in this area. 15:58:52 *have having 15:59:03 Swami: thanks for bringing this up. 15:59:19 Any other issues or concerns. 15:59:26 I see this as our next big acheivement needed to prove out the implementation. 15:59:31 I think we are at the end of the hour. 16:00:03 Please run the experiemental job. We need more runs on it and more eyes on the failures. 16:00:06 carl_baldwin: armax: dvr team: great job, keep up the good work. 16:00:32 See you all next week and thanks for everyone who joined us today. 16:00:33 bye 16:00:36 #endmeeting