14:01:46 #startmeeting neutron_routed_networks 14:01:47 Meeting started Tue May 3 14:01:46 2016 UTC and is due to finish in 60 minutes. The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:51 The meeting name has been set to 'neutron_routed_networks' 14:02:11 #topic Announcements 14:02:18 #link https://wiki.openstack.org/wiki/Meetings/Neutron-Routed-Networks 14:02:24 We're looking forward to Newton-1 14:02:40 It is merely 4 weeks away. 14:02:44 Can you believe it? 14:03:00 yikes 14:03:13 Now is when the rubber hits the road. 14:03:15 :) 14:03:36 Any other announcements? 14:04:23 Summit was good. 14:04:49 A few things came together with Nova which made me very happy. 14:05:01 #link http://releases.openstack.org/newton/schedule.html 14:05:29 #topic Segment CRUD 14:05:43 I'm trying to chase down some +2s for this patch. 14:05:45 #link https://review.openstack.org/#/c/296603 14:06:19 I think it is ready and it will be very good to start a nice merging cadence again. 14:06:24 That's all I have for this. 14:06:39 #topic Associate Subnets to Segments and IPAM 14:06:55 #link https://review.openstack.org/#/c/288774 14:07:48 I haven't looked at the test failures from yesterday. I'll look later today. I've also rebased it and deployed a fresh new devstack with this code running. 14:07:57 Please review. 14:08:27 That's all I have, I think. 14:08:50 #topic Nova Scheduler 14:08:53 mlavalle: hi 14:09:01 hi 14:09:26 I think we have a good plan for this, no? 14:09:34 in the scheduler meeting of yesterday I asked about the next step for our spec in NOva 14:10:10 The plan is that this week they are going to merge the generic resource pools and then they see our spec merged soon after 14:10:46 mlavalle: great 14:10:57 In fact, there is an email from mriedem states this. It is the summary of the Nova Neutron session of last week 14:11:27 * carl_baldwin still trying to slog through the mailing list updates. 14:11:55 mlavalle: Thanks, anything else? 14:12:15 I am also planning to follow up with johnthetubaguy on the work that is being planned for the conductor 14:12:35 and that's it this week 14:12:35 ah, yeah, we need to catch up about that 14:12:50 johnthetubaguy: hi 14:12:57 I am thinking of spliting the allocate_port_for_instance into two bits, dansmith 's idea, basically 14:12:58 johnthetubaguy: please ping me at any time. This is a top priority for us 14:13:02 johnthetubaguy: The work is in good hands. 14:13:52 now the bit we need from you mlavalle, I think is the follow up patches to ensure we get the segment info correctly in the first bit, and correctly set the segment_id during the binding phase 14:14:06 does that make sense? 14:14:25 johnthetubaguy: That might be me. 14:14:50 johnthetubaguy: I'll work on that this week. 14:15:21 johnthetubaguy: My thought now is that the segment_id will be exposed in the fixed_ip part of the port. 14:15:36 I hope to get the spec if for that split soon, I have read through the code around the split 14:15:47 carl_baldwin: we will need the host binding to imply the segment_id though, I assume? 14:16:00 johnthetubaguy: yes 14:16:37 yeah, thats the bit in the second part I guess, we need the other bit in the first half, check if we already have a fixed_ip 14:16:45 sounds like we are thinking along the same lines 14:16:53 mlavalle: does that work for you? 14:17:00 we can obviously catch up more later on 14:17:15 johnthetubaguy: it does. I'll follow up the spec as soon as you push it 14:17:34 johnthetubaguy: thanks for all your help! 14:17:42 johnthetubaguy: I'll take an action to work this up this week in Neutron and post a port create / update response somewhere showing it. 14:18:24 awesome, all sounds good 14:18:38 I should put this meeting in my calendar 14:18:46 ++ 14:18:46 #action carl_baldwin will post port create / update response after port binding info provided. 14:19:07 johnthetubaguy: It is a tricky meeting, the time alternates biweekly. 14:19:19 mlavalle: Anything else? 14:19:31 carl_baldwin: done 14:19:34 #topic Host / Segment Mapping 14:19:43 mlavalle: back to you 14:20:24 carl_baldwin: late last week I pushed next revision. I have a question in the code. Please take a look and let me know what you think 14:20:31 #link https://review.openstack.org/#/c/285548/ 14:20:56 mlavalle: looking... 14:21:22 On the sr-iov mechanism driver, I did great progress yesterday with the refactoring. I expect to push the paqtchset today or tomorrow 14:21:51 And as you know, I already had a conversation with Irena, so I will have her review the patchset as soon as it is up 14:22:06 carl_baldwin, mlavalle: isn't this supposed to be plugin agnostic? seems like that is tightly coupled with ml2 14:22:19 blogan: You beat me to it. 14:22:41 mlavalle: This does look like ML2 internals leaking in to the core. 14:22:59 mlavalle: We'll need to work on an interface that other plugins can implement. 14:23:09 +1 14:23:38 carl_baldwin: sounds good 14:24:34 mlavalle: The code here should do the right thing when the plugin doesn't implement the interface. 14:24:48 mlavalle: We should be sure to have OVN guys review the interface. 14:25:05 ok 14:25:23 mlavalle: Thanks for raising that concern. 14:26:12 mlavalle: I'll look through the rest later today. 14:26:20 carl_baldwin: thanks 14:27:00 mlavalle: Good work, anything else? 14:27:08 I'm done 14:27:32 #topic Create / delete segment in ML2 14:27:39 xiaohhui doesn't seem to be on. 14:28:11 He had a long trip to attend the summit. Probably needs a little time to recover from jetlag. 14:28:17 We'll move on ... 14:28:31 #topic Segment aware DHCP 14:28:33 is carlag a thing? i'm suffering from that 14:28:56 so i have a very WIP review up https://review.openstack.org/#/c/311931/ 14:28:59 blogan: Maybe, but I'm sure that summitlag is a thing. I had that over the weekend. 14:29:16 blogan: I noticed it post this morning. Great news! 14:29:47 i'm not a big fan of one of the things i had to do but i wanted to have something that kind of worked, but i'll need to go a different path 14:29:59 I'll take a look. 14:30:01 the problem is in the filter and how the scheduler calls it 14:30:24 blogan: Do you have a comment marking that one thing? Maybe other reviewers and I can try to provide some ideas. 14:30:34 also, the review is depending on https://review.openstack.org/#/c/288774 14:30:38 carl_baldwin: yes i do 14:30:45 made sure i did so people didn't yell at me lol 14:30:54 blogan: :) 14:31:17 288774 is about the right place to insert this functionality right now. 14:31:27 anyway, this patch is kind of dependent on 2 patches, the one above and the segment host mapping one mlavalle is working on 14:32:08 blogan: That is a good point. My IPAM work is in the same predicament. 14:32:43 blogan: For now, I was hacking around the lack of host / segment mapping because that is also a WIP. 14:32:50 yeah so in this case would it be prudent to just put mlavalle's patch on top of 288774? 14:32:58 even though its not dependent 14:33:14 mlavalle: What are your thoughts? 14:33:36 carl_baldwin, blogan: that is fine with me 14:34:00 mlavalle: If mlavalle 's patch is far enough along to be useful, I'd say yes. But, if it is still heavy WIP then maybe we can try to fake it in the meantime. 14:34:28 I'm still okay faking it for what I need. But blogan 's work is different than what I'm doing. 14:34:58 yeah there's still plenty i need to do in the meantime, and i feel like it'll be relatively simple to integrate whenever i'm able to use it so not too big of a deal 14:35:30 mlavalle: blogan: I'll see what I can do about merging those patches this week. 14:35:45 I mean the CRUD and the subnet / segment patch. 14:36:05 carl_baldwin: ill take one last pass over them today, they do look pretty good though 14:36:26 blogan: Thanks, your feedback has been good. I appreciate it. 14:36:47 blogan: Anything else on this topic? 14:36:57 nope, thats all i got 14:37:16 blogan: Thanks. 14:37:23 #topic L2 adjacency 14:37:49 * carl_baldwin just realized he skipped the client. We'll get the client next. 14:38:17 reedip made it to the summit. That's good but I'm sure he's jetlagged too. 14:38:32 aw i didn't get a chance to meet him 14:38:35 he doesn't seem to be on 14:38:56 I did want to say one thing about this before I forget. 14:39:38 blogan: suggested that we make this a separate extension and we decided not to. But, now I think we should. 14:40:18 ... for a different reason. The reason is so that a plugin like Calico can implement the extension to say "we don't provide L2" without having to pull in the segments extension. 14:40:28 ahh good point 14:40:59 I'll provide that feedback on the spec before I forget. 14:41:03 #topic Client 14:41:11 rtheis: hi 14:41:14 hi 14:41:16 also a good exmaple of something true microversioning would not support easily 14:41:29 not much new on client patches 14:41:46 I need to follow-up on summit session for transition to osc to make sure where the code belongs 14:41:58 python-neutronclient or python-openstackclient 14:42:22 I had to leave summit on Tuesday so didn't get to attend that session 14:42:43 i figured it'd be the neutronclient but i was not part of any of those discussions 14:43:25 rtheis: I wasn't able to attend either. I had a talk. 14:43:42 rtheis: I'm afraid I'm not current on the discussion and can't provide feedback. 14:43:50 I'll follow-up on the ML email sent before the summit 14:44:06 rtheis: Sounds good 14:44:38 I did put out 3 WIP patches for enabling python-neutronclient to support OSC plugins 14:45:02 that would be pre-req to move my client patches from OSC to neutronclient 14:45:34 that's all I have 14:45:34 rtheis: ack 14:45:42 rtheis: thanks 14:45:59 #topic OVN and routed networks 14:46:54 Hmmm, I don't think we have anyone here for this. xiaohhui is jetlagged and russellb is a daddy again. 14:47:34 #topic Floating IPs with no router 14:48:14 I wanted to make sure this was on the agenda. It might be a stretch goal for Newton but I think it would be good to have an owner. 14:48:35 I need to check back with GoDaddy and Calico to see if we can find someone to start looking at it. 14:49:13 carl_baldwin: i'm not sure exactly how what would be implemented, could you give a quick summary? 14:49:40 other than making router_id optional in a fip request 14:49:58 blogan: Is there a router_id in the fip request? 14:50:15 there isn't 14:50:21 i coulda sworn, oh bleh i'm confusing it with needing the floating network to be connected to the router 14:50:23 sorry lol 14:51:05 There is a router_id in the response. 14:51:10 yeah 14:51:10 That's a good point. 14:51:38 Right now, you create a floating IP and then you associate it with a port. 14:51:59 At that point, Neutron jumps in and looks for a router between the two. 14:52:42 The idea would be to allow this fip <-> fixed port association without a router. 14:53:39 In our case, it would be on the same network. In Calico's case, I think they just assume all networks are implicitly routed and it could be any network. 14:54:09 I probably should call neiljerram to be sure. 14:54:27 that makes sense for calico's case 14:54:41 but for our cae, the fip would be on the same network as the port? 14:54:48 blogan: right. 14:55:34 it's just another segment, right? 14:55:38 It would be good to have a discussion about how different plugins might be able to impose different constraints and allow different associations. 14:56:08 mlavalle: In our case, the floating ips wouldn't be tied to any segment but the fixed ips would be. 14:56:34 ah the fip would be able to route to any segment 14:56:43 in the network 14:57:16 blogan: right 14:57:32 okay its becoming more clear to me now, thanks for educating carl_baldwin :) 14:57:37 Anyway, we're almost out of time. I just wanted to get that out there. 14:58:14 #topic Open 14:58:18 Anything else? 14:59:05 none fo rme 14:59:12 I'm fine 14:59:46 Thanks everyone! Hopefully all the others can recover from travels quickly. It stinks to be wiped out from a long trip. 14:59:59 #endmeeting