15:02:39 #startmeeting neutron_l3 15:02:40 Meeting started Thu Jun 18 15:02:39 2015 UTC and is due to finish in 60 minutes. The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:43 The meeting name has been set to 'neutron_l3' 15:02:51 #info regXboi (Ryan Moats) 15:02:58 #topic Announcements 15:03:02 carl_baldwin: as promised/threatened :) 15:03:25 Hi carl 15:03:35 hi 15:03:46 hello 15:03:53 I’d like to welcome haleyb as our first core focusing on the L3 area. 15:03:53 hi 15:03:54 hi 15:04:01 hi 15:04:05 #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam 15:04:08 Yay! 15:04:13 haleyb: congrats 15:04:39 haleyb: welcome, congrats 15:04:39 haleyb: yeah, congratulations! 15:04:41 The Neutron mid-cycle is next week in Fort Collins. I look forward to seeing as many of you as possible. 15:05:03 carl_baldwin: looks like I can make it now :) 15:05:16 johnbelamaric: great 15:05:21 #link https://etherpad.openstack.org/p/neutron-liberty-mid-cycle 15:05:24 thanks, i look forward to helping out more 15:05:29 Also, Liberty-1 is next week too. 15:05:41 carl_baldwin: is there any change the mid-cycle will have an IRC channel or way for remotes to get involved? 15:05:50 s/change/chance/ 15:05:57 Hi 15:06:21 regXboi: mestery has put a note at the bottom of the etherpad. 15:06:33 #topic Bugs 15:06:43 carl_baldwin: thanx, I see that - will bug mestery (I'm good at that) 15:07:43 Thanks to mlavalle for helping us to stay on top of the bugs with the l3-ipam-dhcp tag 15:07:53 carl_baldwin: :-) 15:08:01 Our bug list is shrinking. That is good. Just in time to write some more. ;) 15:08:27 #topic Routing Network Segments 15:08:39 This is the hot topic for today, I think. 15:08:43 :) 15:09:22 So, where do we start? I guess I could get a couple of links. 15:09:42 always good for the minutes :) 15:10:12 I am a bit out of the loop on this. Is it intended to cover all the various segmentation strategies that the operators are mentioning (no two seem to be the same)? 15:10:12 #link https://bugs.launchpad.net/neutron/+bug/1458890 15:10:14 Launchpad bug 1458890 in neutron "Add segment support to Neutron" [Undecided,Triaged] 15:10:18 ^ this is the rfe 15:10:47 HenryG: I guess that is what we’re here to discuss. 15:11:01 #link https://review.openstack.org/#/c/172244/ 15:11:14 ^ This is the spec that I wrote with a similar network segments concept. 15:11:47 I guess the first question is whether the spec covres the rfe? 15:12:44 * HenryG pings baoli to pay attention because he was asking about this 15:12:51 regXboi: Not entirely. The spec is written for a different use case. However, it does introduce network segments which map to a given set of hosts. 15:13:14 I believe that the network segment idea could be shared between the two. 15:13:22 carl_baldwin: I think I saw a comment from you that the spec was at best partial coverage because of that (am I remembering correctly)? 15:13:46 Beyond network segments, the rfe talks about some Nova work to pass a segment id when creating a port and then using IP usage information in scheduling. 15:14:25 regXboi: Yes, just to be clear: The spec does not completely cover the use case in the rfe. 15:14:44 carl_baldwin: a concern - how would this rfe interact with the multiple provider extension? 15:15:07 * regXboi worries about overloading the segment concept 15:15:35 regXboi: Good point, it did not cross my mind yet. 15:16:38 carl_baldwin: I would like to think that we could start from that point, although it risks conflating physical segmentation with the rfe, which wants to include logical segmenation 15:17:22 regXboi: Right, I think it is worth some of my time to reconcile these with multiple provider extension. 15:17:39 carl_baldwin: I'd be willing to pitch some cycles there as well 15:18:45 because I think it might be possible to pull all three (mpe, rfe, backing networks) together 15:19:43 regXboi: I think you’re right. At least find the commonality and use it to build a good base for the rfe and routing network segments to build from. 15:19:45 regXboi: Any links to info on the multiple provider extension? 15:20:05 #link http://developer.openstack.org/api-ref-networking-v2-ext.html 15:20:13 * pc_m trying to come up to speed on this 15:20:20 regXboi: Thanks! 15:20:25 pc_m: yw 15:20:37 pc_m: Under “Networks multiple provider extension” 15:20:59 yeah found it. thanks. 15:21:00 regXboi: Let’s do some homework today and maybe we could meet in the neutron room tomorrow at some time for a discussion. 15:21:31 carl_baldwin: sounds like a plan - I'll check my calendar and hit you with some times I can be there 15:22:29 regXboi: Great. Anyone else want to be notified of the time? 15:22:40 If so, ping regXboi 15:22:55 sure 15:22:56 Okay. Anything else on network segments that we should hit today? 15:24:07 I plan to attend the LDT meeting after this meeting. We may mention it there too. 15:24:38 carl_baldwin: feel free to let folks there know to ping me for notification about tomorrow's times 15:24:46 regXboi: I will. 15:24:50 :) 15:24:52 carl_baldwin: What channel? 15:25:06 pc_m: LDT? 15:25:09 for the LDT meeting 15:25:17 #link https://wiki.openstack.org/wiki/Meetings/LDT 15:25:30 thx 15:25:56 #topic bgp-dynamic-routing 15:26:13 tidwellr: ping 15:26:21 hey 15:26:35 How are we doing here? 15:27:09 Hi. I think I log in time 15:27:39 devvesa: You are here. Hi. Didn’t mean to miss you. 15:27:52 I think we're in good shape . I'm working on another patch set for the API/DB layer. I'm taking the time to do API tests as I go. 15:27:56 Oh, just logged now :) 15:28:03 Sorry 15:28:38 tidwellr: Are all of the patches on a topic we could like to here? 15:28:48 devvesa: Good timing. 15:29:12 bp/bgp-dynamic-routing 15:29:59 #link https://review.openstack.org/#/q/topic:bp/bgp-dynamic-routing,n,z 15:30:10 tidwellr, carl_baldwin: is there a plan for incorporating these tests into the gate? 15:30:27 I ask because I suspect the LDR folks will want to tune that test for their specific deployments 15:30:37 yes, that needs to be done, not sure how to start though 15:31:02 (sorry LDT, not LDR) or is the plan to have that in 3P/CI testing so that each LDT can tune it as needed? 15:31:51 I've a little myopic about just getting tests running in my environment, but my intention is to have a CI job for BGP 15:32:29 could use a little help there...... 15:33:21 tidwellr: unfortunately, I'm not sure I can commit to that, but let me look around and see if I can scare up some help... 15:34:33 Well, let’s hit the reviews and keep our eye on building tests for the gate. 15:34:38 Anything else for this topic? 15:34:59 #topic neutron-ipam 15:35:17 hi 15:35:19 not from me, devvesa? 15:36:02 pavel_bondar: great work on breaking up the large review. It is a lot easier to review now. It is nice to have check-points along the way. 15:36:23 neither. Just waiting your next patch, tidwellr :) 15:36:24 I have created 3 more review today:) 15:36:38 next review in chain to be merged is #link https://review.openstack.org/#/c/189299/ 15:37:08 and 6 more reviews are on top of that 15:37:46 pavel_bondar: nice, lots of work but I think it is much easier this way 15:38:18 pavel_bondar: This one is looking pretty good. 15:38:21 johnbelamaric: agree 15:38:38 carl_baldwin: nice 15:39:12 I can post full review chain into IRC if needed 15:39:15 So, we just keep going. Reviewers can start with this^ and follow the chain. 15:39:37 pavel_bondar: Probably not needed. 15:39:49 carl_baldwin: ok 15:39:58 Anything to discuss? 15:40:21 #topic ML3 Router plugin 15:40:31 Anyone here to give a report on this? 15:40:37 Hello. 15:40:46 So far we gathered the use cases in etherpad 15:40:53 https://etherpad.openstack.org/p/neutron-modular-l3-router-plugin-use-cases 15:41:17 They are for requirement. 15:41:43 So the next step is to define operation scenario in order to define desired API or CLI operations 15:42:00 pcarver: ping? 15:42:01 yamahata: Use Case #4 looks very close to service chaining - is that intentional? 15:42:08 These look good. 15:42:34 regXboi: Yeah. the difference is that the service is on edge. 15:42:46 If SFC supports it, it's quite fine with it. 15:43:52 Deployer may think SFC is overkill. they may want more simpler way to just deploy single function. 15:43:52 yamahata: got it - but I need to go off and think about whether you've just created an SFC implementation unintenionally 15:44:12 yamahata: I'm not saying that's a bad thing 15:44:24 * regXboi needs to think about the implications 15:44:40 regXboi: I don't want to reinvent SFC. 15:45:02 pcarver doesn't seem here. Contact him off line. 15:45:18 yamahata: understood, like I said, let me think about the implications 15:45:31 regXboi: sure. 15:45:45 yamahata: How do we go about the next step? 15:46:13 I'll write up a draft for desired operation scenario. then get review. 15:46:27 yamahata: Sounds like a plan. 15:46:43 Anything else? 15:46:55 #topic dns-resolution 15:46:58 mlavalle: ping 15:47:25 Kiall helped us to respond to the concerns in https://review.openstack.org/#/c/88623 15:47:40 I was looking at those this morning. 15:47:52 He added a comment yesterday. I'll update the spec today 15:48:29 He also wrote the discussion in vancouver to https://review.openstack.org/#/c/88624/, so it is looking good 15:49:26 The nova side https://review.openstack.org/#/c/90150/ was refreshed by me laste last week andgot a +1. Will follow up with johnthetubaguy to get it reviewed by him 15:49:53 mlavalle: I assume you are looking for reviews on updated 88623 and 88624? 15:50:03 And I am already coding for https://review.openstack.org/#/c/88623 15:50:17 regXboi: yes 15:50:18 mlavalle: Good progress. 15:50:33 mlavalle: thx 15:50:36 I should push WIP patchset soon 15:51:19 Kial comments to 88623 change code a bit, but not much. 15:51:27 that's all I have 15:51:51 mlavalle: I look forward to seeing it. Ping at least haleyb and me for reviews. And, anyone else interested. 15:52:00 will do 15:52:23 #topic Address Scopes 15:52:28 * mlavalle looking forward to get review from our brand new core :-) 15:52:54 I added an update to the BP: https://review.openstack.org/#/c/192914/ 15:53:24 Otherwise, I’m coding now and hope to have things working on the L3 agent side in a couple of days. 15:53:41 The address scope crud work has also started. 15:54:02 https://review.openstack.org/#/c/189741/ 15:54:17 Vikram is still on vacation but should return soon. 15:54:26 #link https://review.openstack.org/#/c/189741/ 15:54:44 #topic IPv6 15:55:09 Anything here? I know I’ve been neglecting the PD reviews. I’ve been trying to get to it and will soon. 15:55:40 carl_baldwin: Thanks, I know it’s a big patch! 15:57:36 In general, this needs more reviewer attention. Not just from cores. I’d like to see it start to build some consensus with multiple +1s. 15:58:04 * haleyb needs to re-review the PD changes as well 15:58:20 Here’s the first PD patch in the chain: https://review.openstack.org/#/c/158697 15:59:05 How can we get more attention on this from the community? 15:59:08 The second is currently in merge conflict with the ongoing db_plugin_v2 decomp work 16:00:12 carl_baldwin: Reviews keeping it near the top of the list will help, otherwise I could spam the mailing list with demo videos :) 16:00:13 I guess our time is up. 16:00:25 We can take stuff to the neutron room. 16:00:27 #endmeeting