15:01:22 #startmeeting neutron_l3 15:01:23 Meeting started Thu Jun 26 15:01:22 2014 UTC and is due to finish in 60 minutes. The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:23 carl_baldwin: come on don’t be :) 15:01:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:26 The meeting name has been set to 'neutron_l3' 15:01:49 #topic Announcements 15:02:24 Mid-cycle sprint is coming up in almost two weeks. 15:02:24 hi 15:02:28 #link https://etherpad.openstack.org/p/neutron-juno-mid-cycle-meeting 15:03:06 aloha 15:03:19 Juno-2 is well underway. I think it is July 24th. 15:03:28 tmorin: salv-orlando: hi 15:03:56 Our big priority is to get DVR code merged by then. 15:04:31 #topic neutron-ovs-dvr 15:04:54 Do we expect Swami today? 15:05:21 doubtful - he is OOO 15:05:33 Yeah, just hoping. :) 15:05:48 +1 15:05:50 Many of the patches have seen a lot of improvement in the last week. 15:06:05 #link https://review.openstack.org/#/q/topic:bp/neutron-ovs-dvr,n,z 15:06:49 All but one were passing Jenkins yesterday. That is a big improvement over just one week ago. 15:07:11 carl_baldwin: I expect to make further progress by the end of the week 15:07:40 I’m mostly happy with https://review.openstack.org/84223 now. That is the first one that needs to merge. 15:08:04 carl - one note on that patch 15:08:08 carl_baldwin: there are still a few weaknesses that I think we can address, but all in all I am pleased to see the amount of work that went in to give the patches a better structure 15:08:14 one of the reviewers on the l3-agent patch 15:08:30 noticed some snat functionality is missing from the l3-extension patch 15:08:30 armax: ++ 15:08:46 I'll add a comment to the same on the l3-ext patch 15:10:06 mrsmith: Thanks for pointing that out. I agree that there are some weaknesses but I feel like the patch is ready for broader reviewing. 15:10:12 mrsmith: is it a result of a bad merge or revision gone sour, or is it something that was never there in the first place? 15:10:16 mrsmith: Is this something you know how to address? 15:10:28 yes - we changed the snat port communication late in the game 15:10:37 we just need to update the patch with what we have locally 15:10:45 not a big deal 15:10:47 mrsmith: cool 15:11:19 mrsmith: Thanks. 15:11:22 np 15:11:33 and it only effects DVR snat 15:11:38 not legacy/regression 15:11:41 mrsmith: are you going to push a new revision to swami’s patch or shall we coordinate amongst the larger group? 15:12:12 no sure - I haven't been tracing the progress of that patch as much as others 15:12:17 we can chat offline 15:12:22 ok 15:12:25 *not sure 15:12:36 let’s take this offline than 15:12:42 you know how to find me or carl_baldwin 15:12:49 yup :) 15:13:15 mrsmith: Once we get that part in shape then I’d like to ping one more core to review the patch for another perspective. 15:13:30 yes - even now... I think the core stuff is there 15:14:04 mrsmith: Great. 15:14:13 mrsmith: so we might want to consider to have the addition closer to a downstream patch 15:14:33 possibly... 15:14:36 armax: ? 15:14:38 mrsmith: I mean where it’s used, but then again, let’s talk later 15:14:56 it comes back to carl (and other's) wish to pull the patches together as-is and have DVR work 15:15:21 legacy may work - but DVR will not 15:15:41 Okay. Let’s move on. 15:15:54 mrsmith: right, but legacy is the deafult code path being tested 15:16:01 agreed 15:16:02 yup, let’s move on 15:16:31 armax: Nice work splitting up 87730 in to multiple patches. 15:16:50 What is the status of those patches? I’ve been through a couple of review cycles but I lost track of it yesterday. 15:17:08 carl_baldwin: I need to push one more revision to update the one on the models 15:17:25 carl_baldwin: but it won’t take me long 15:17:32 carl_baldwin: I just need to find the time ;) 15:18:05 Understood. I’ll watch for the updates and try to get my feedback up promptly. 15:18:39 Other reviewers are welcome too. Please try to do comprehensive reviews. 15:19:23 ++ 15:19:32 mrsmith: How is https://review.openstack.org/#/c/89413/ ? 15:19:52 yes, the fewer revisions we can do the better 15:20:00 going well 15:20:09 I plan to create a new dvr_util.py file 15:20:18 to hold some of the pure dvr methods 15:20:18 mrsmith: Great work on the tests. Jenkins has been passing which relieves some concern. 15:20:24 as suggested by armax 15:20:45 a few other cleanups to do 15:20:50 mrsmith: yes, let’s see how it looks 15:20:50 otherwise pretty stable 15:21:04 yesterday I was speaking with Murali and I have some doubts 15:21:05 I hope to update again soon 15:21:11 on some of the config options made available there 15:21:12 Will you have time to do another turn-around on it? 15:21:21 I wonder whether we can consolidate some of them 15:21:23 I hop so 15:21:27 armax: made where? In Murali’s patch? 15:21:35 no mrsmith 15:21:36 's 15:21:45 three bool options have been defined 15:21:55 mrsmith: Please reach out if you think I can help. I’ll make time for whatever I can do. 15:22:02 thanks 15:22:08 armax - doubts on the config? 15:22:09 however of the 8 combinations available only a handful would make sense 15:22:35 so I wonder if we can abstract soem of them, instead of talking binary we can talk English 15:22:36 armax: +1 I’ve wondered about that. 15:22:49 mrsmith: I’ll take that on the review, it’s the best place to discuss this 15:22:54 I'm open to suggestions 15:23:09 mrsmith: sure 15:23:13 we tried to keep things simple and yet support many setups 15:23:18 I am open to giving them :) 15:23:33 for example - single node setup may not make sense 15:23:34 We’ll look for that discussion on the review. 15:23:41 but we may need to support it for tests 15:23:55 agreed, but I had a hard time wrapping my head around them, I wonder what an operator would do if he does not want to dive in the code 15:24:04 sure 15:24:33 mrsmith: I think my concern is more an usability issue rather than correctness of the solution proposed 15:24:41 s/an/a 15:24:53 anyhoo let’s move past thsi 15:24:57 armax: ok - we want usability (aka ease of use) 15:24:59 *this 15:25:06 Is Murali on IRC? I don’t know his nick. 15:25:25 don't think so.. 15:25:33 probably woulda chimed in by now 15:26:03 carl_baldwin: maybe I can help 15:26:07 I spoke with him last nite 15:26:08 I’m most concerned about https://review.openstack.org/#/c/89694/. 15:26:23 carl_baldwin: what do you wanna know? 15:26:48 The Jenkins failures mostly. I fear that reviewers are not giving it any attention because of the failiures. 15:27:14 carl_baldwin: correct 15:27:25 this is the only patch that has never passed tests so far 15:27:50 I have a pretty good understanding why Tempest tests are failing 15:27:57 I can look at the UT too 15:28:02 Right. From one perspective, that is great progress. 15:28:18 so if Murali doesn’t beat me to it I’ll bash the patch into shape later today 15:28:23 armax: Would you like some help with the UTs? 15:28:37 yesterday we had a different failure mode as of today 15:28:45 so I need to look at it again 15:28:50 armax: What is up with the Tempest tests? 15:29:01 carl_baldwin: if you can spare a few minutes that’d be great 15:29:14 Yes, I can make time for it. 15:29:18 carl_baldwin: fundamentally Murali’s patch depends on mrsmith’s 15:29:21 that said… 15:29:42 I did follow your rebase. Good move. 15:29:43 that is only true for the ‘distributed’ code path 15:29:54 armax: right 15:30:00 the centralized code path shouldn’t be affected 15:30:01 legacy shouldn't be affected 15:30:18 but it looks like the scheduler code being proposed alters that 15:30:36 and when a tempest test tries to add a rotuer to an agent 15:30:39 armax: alters it how? 15:30:51 neutron is not able to find an eligible agent 15:31:10 it alters the election logic to find a suitable agent to move the router on 15:31:39 I pinpointed the problem in the code when speaking with Murali 15:32:18 then he pushed another patch but it doesn’t seem it did any effect so I need to see at the diff he pushed 15:32:28 armax: Since you have a handle on that. I’ll leave you to it but I will plan to get to the UTs later today. 15:32:39 greate 15:32:40 great 15:32:44 thanks 15:33:37 Sorry to take the whole meeting for DVR but I have one more thing. 15:33:56 We have 7 interdependent patches in flight. 15:34:22 I prefer this over the larger patches but it does present problems of its own. 15:34:45 if there’s nothing else, maybe we can move on 15:35:17 With different authors on different patches it is easy to clobber things. 15:36:16 carl_baldwin: true, but that’s the nature of collaborative open source business :) 15:36:50 carl_baldwin: can’t argue with the fact that things could’ve been simpler 15:36:56 I think uploading patches with —no-rebase is a good idea. The problem this avoids is that otherwise, uploading a patch rebases the dependent patches which another author may be working on. 15:37:04 carl_baldwin: but there’s always a lesson to be learned 15:37:35 But, this means that we’ll need to think about rebasing consciously because we can’t get behind by more than a day or two. 15:38:04 Thoughts? 15:38:51 carl_baldwin: it’s difficult because it depends on the punctual state the patches are in 15:38:56 and how trunk moves forward 15:39:16 in theory we can have people do git-review with --no-rebase 15:39:30 and have a person that does a single sweep twice a week for instances 15:39:52 but then what happens if the root patch goes sour and merge conflicts arise? 15:40:16 so maybe we can use —no-rebase as the committer’s default action 15:40:16 I’d prefer that. I am willing to watch the patches and ping authors when they need to rebase. 15:40:39 and if a merge conflict arises we you or I can do a global sweep 15:40:49 you as in carl_baldwin 15:41:09 Merge conflicts are inevitable. They will happen either way. I’d just prefer they happen when the author is ready. 15:41:41 Yes, I am willing to handle it because I think it will be better for authors to not have their patches moved out from under them. 15:42:59 I’ll watch daily for any patch that is two days out of date from its upstream. 15:43:14 cool 15:43:24 Okay. Anything else on DVR? 15:44:19 #topic l3-svcs-vendor-* 15:44:21 pcm_: hi 15:44:24 Hi 15:44:25 Any update here? 15:44:40 Have reference implementation out for review #link https://review.openstack.org/#/c/102351/4 15:45:10 Having a Jenkins failure, 'process-returncode'. Not sure where the error is on that. Could use some ides. 15:45:14 ideas. 15:45:38 process-returncode is not interesting by itself. Are there other failures? 15:45:38 Have a Cisco patch ready for review, but waiting, until I can get the ref one clean. 15:45:38 isn't the real failure is another one? 15:45:51 ie. test_reference_driver_used 15:46:00 Yes, the other failure is the interesting one. 15:46:17 It shows two failures in the summary, but only FAIL line I see is for process-returncode 15:46:19 odd 15:46:34 #link http://logs.openstack.org/51/102351/4/check/gate-neutron-python27/a757b36/console.html 15:46:43 Yeah, there isn’t much in the report at all. 15:46:59 look at testr_results 15:47:09 yamamoto: OK will do. 15:47:31 I looked and it doesn’t have much. 15:47:40 pcm_: Does that test pass locally for you? 15:48:39 On the last run (in a VM) I get the same result, though I occasionally get unrelated errors on runs. 15:48:50 Rerunning again to see. 15:49:05 We should probably take this out of the meeting. Ping me later today on it. 15:49:16 will do 15:49:26 You’ll want to have Jenkins passing fully to get on reviewers radar. Anything else? 15:49:42 #topic l3-high-availability 15:49:45 Nope. I had it working in V2, but made a change and it failed. 15:49:55 safchain: Are you around? 15:51:14 #topic bgp-dynamic-routing 15:51:24 nextone92: devvesa: hi 15:51:28 o/ 15:51:49 I didn’t quite finish my review of your bp. I need to finish that today. 15:52:12 I wanted another look at the diagrams. 15:52:13 ok, great 15:52:27 Did you see my comments? 15:52:33 yes 15:52:59 thanks for respond the questions 15:53:09 Could those points be worked in to the bp to make things a little clearer? 15:53:25 yes, sure 15:53:49 I'll wait your today's review and I'll prepare another patch 15:54:02 Okay. I don’t promise I’ll get to it early. 15:54:15 But, I will get to it. 15:54:25 6pm here. today's review will be tomorrow for me :) 15:54:36 Okay. 15:54:39 Anything else? 15:54:55 last week, yamamoto was wanting an intro on bagpipe 15:55:09 I'm avail if people have questions 15:55:40 tmorin: Thanks. I’m sorry I haven’t given that thread any attention yet. It is still in my queue. 15:56:17 well, I guess the question is the choice of BGP speaker for bgp dynamic routing 15:56:36 we are working to implement the bgp vpn connectivity blueprint with bagpipe 15:56:45 Only for the reference implementation. I think there will be multiple implementations given the interest that I’ve seen. 15:57:06 yes, possibly so 15:57:29 tmorin: Are you working with Nachi on that? 15:57:50 on the bgp vpn connection bp ? yes 15:58:03 Great. 15:58:12 keshava also seemed to be interested in bgp-vpn 15:58:38 yes 15:58:46 we had a discuss on the list 15:58:55 Yes. There is plenty of interest. 15:59:05 anyways, if people want to investigate bagpipe for the dynamic (non-VPN) routing bp, feel free to ping me 15:59:17 We’re almost out of time. Let’s keep the ML threads going. I will add my thoughts soon. 15:59:18 the non-VPN case should be easy to add to bagpipe 15:59:21 ok 15:59:23 thanks 15:59:31 tmorin: I'll take into account for sure 15:59:42 #topic neutron-ipam 15:59:48 great, we're open 15:59:52 We have 10 seconds. :) 16:00:00 I just wanted to say I haven’t forgotten about this topic. 16:00:22 I am part way through a review of the bp but other priorities have starved it. 16:00:24 Hi - I'll be short I have all changes in bp and we are still on track for juno-2 16:00:36 I encourage reviewers with interest to go add their comments and keep it going. 16:00:52 seizadi: Thanks for keeping the momentum going. 16:01:02 That is all we have time for. 16:01:06 #endmeeting