21:01:44 #startmeeting networking 21:01:44 Meeting started Mon Jun 10 21:01:44 2019 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:49 The meeting name has been set to 'networking' 21:01:59 hi everybody 21:02:07 hi 21:02:09 hi 21:02:38 howdy 21:02:51 o/ 21:02:56 o/ 21:03:24 I think most of the people are already here 21:03:27 slaweq and bcafarel are both off today 21:03:36 so lets get going 21:03:45 #topic Announcements 21:04:25 we passed the T-1 milestone last week 21:04:52 Next Milestone is T-2, week of July 22 - 26 21:05:20 * mlavalle shudders thinking that at that point will be cooking at 100 degreees here in Austin 21:05:35 you too, wwriverrat 21:05:50 What swimming pools are for :-P 21:06:10 * tidwellr wonder what he would give for those temps 21:06:51 and the call for papers for Shangai has a deadline of July 2nd 21:07:36 any other announcements? 21:08:32 ok 21:08:41 #topic Blueprints 21:09:10 First of, let's talk about https://blueprints.launchpad.net/neutron/+spec/multiple-segment-per-network-per-host 21:09:42 I spent a good chunk of time yesterday looking at https://review.opendev.org/#/c/623115 21:10:04 it overall looks pretty decent 21:10:21 I didn't find anything "hairy" to worry about 21:10:39 and you have it running in your deployment, right wwriverrat? 21:11:27 Yeah. Our version is a pike backport and it makes no assumptions about anything but LinuxBridge 21:12:02 looking at the code, it doesn't seem to me that we need to change much, if at all, for an OVS based deployment 21:12:10 The WIP patch does have holes in a few places even for LinuxBridge 21:12:26 1) When you delete networks, it wont delete all segments 21:13:37 I was working on changing the dict (network_id: segment) into something like dict (network_id, list) and the list would be all segments 21:14:27 do you plan to address these holes anytime soon? 21:14:32 wwriverrat ^^^ 21:14:40 Changing that structure affected other code. 21:14:51 I could and update that WIP 21:15:26 I'm curious about all it would break :-O 21:15:36 here's what I would like to happen: target this code to merge by end of July (T-2 milestone) 21:15:54 I will partner with you testing and changing (if needed) for OVS 21:16:16 I stood a test system with routed networks and all OVS last night 21:16:40 awesome 21:16:49 so I am planning to start testing the patch with OVS as it is today 21:17:12 that way we can fill out the OVS portion of the spec 21:17:28 My change effectively changes the `self.network_map` here where the value is a list of segments: https://github.com/openstack/neutron/blob/cbee0f9f88ff34f70ff19590471b5405e06ff2a9/neutron/plugins/ml2/drivers/agent/_agent_manager_base.py#L62-L68 21:17:36 (newest changes) 21:17:45 and I intend to enroll someone for SR-IOV 21:17:55 awesome 21:18:06 do you feel comfortable working towards the T-2 milestone? 21:18:51 sure. I'll dust off this work and put in some effort to get this much closer 21:18:57 cool 21:19:57 tidwellr: is it ok if I create a blueprint for the subnet pools RFE that we approved this past Friday and add it to the T-2 dashboard? 21:20:17 sure 21:20:25 perfect 21:21:04 and I will talk to rubasov tomorrow morning in regards to his extra routes work 21:21:32 it is almost bed time for him now 21:21:44 any other blueprints we should talk about today? 21:22:46 thanks for joining us wwriverrat :-) 21:22:56 my pleasure 21:22:59 ok, moving on 21:23:06 #topic Bugs 21:23:27 Our deputy last week was haleyb 21:23:55 This is his report http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007040.html 21:24:09 not too many bugs last week, most have either patches proposed or owners 21:24:14 one critical bug 21:24:23 https://bugs.launchpad.net/neutron/+bug/1832225 21:24:24 Launchpad bug 1832225 in neutron "Neutron-vpnaas unit tests broken" [Critical,In progress] - Assigned to Slawek Kaplonski (slaweq) 21:25:10 probably caused by https://review.opendev.org/#/c/653903/ 21:25:26 slaweq has proposed https://review.opendev.org/#/c/664257/ 21:26:02 but it looks like there's some unrelated failures in the vpnaas check queue 21:26:08 yes 21:26:28 let's keep an eye on it 21:26:48 slaweq probably won't have time to work on it until Wednesday 21:27:34 right, he's at openstack days poland (?) 21:27:47 +1 21:27:48 * haleyb really should know this 21:28:31 one other bug i had a question on, https://bugs.launchpad.net/neutron/+bug/1831726 21:28:32 Launchpad bug 1831726 in neutron "neutron-cli port-update ipv6 fixed_ips Covering previous" [Undecided,Incomplete] 21:29:23 from my triage it looked like the API was doing the right thing, but the openstackclient was different from the neutronclient 21:29:48 I'll keep an eye on it 21:30:09 i didn't know if someone else had a definitive answer on that, i just know that osc-lib, etc, sometimes does things differently 21:30:40 amotoki is the person who most likely knows that 21:30:53 i.e. a port-update will load the current port and send more info back in osc 21:31:31 i will ping amotoki tomorrow if he's not here 21:31:51 cool 21:32:10 I am the deputy this week, so if I need to follow up please let me know 21:32:15 thanks everyone for picking up the bugs you filed :) 21:32:25 I have one to bring up 21:32:27 ack 21:33:17 do we have a min for me to mention it? 21:33:22 yes 21:33:25 https://bugs.launchpad.net/neutron/+bug/1830679 21:33:26 Launchpad bug 1830679 in neutron "Security groups RBAC cause a major performance degradation" [High,New] 21:33:58 I just want to make sure it doesn't fall off the radar... not sure who's going ot have the time to address it so maybe consider a revert 21:35:27 we dont have to discuss here, but I'm hoping we can move forward on it :) 21:35:32 in the not to far future 21:36:04 boden: I went over it quickly. I will take a look at the mentioned patches and see if I can do something 21:36:12 thanks 21:36:22 I'll make sure we revisit it next week as part of my deputy duties 21:36:37 reach out if needed 21:36:53 I'll assign it to myself for the time being 21:37:30 thanks and sorry about that 21:38:02 #topic neutron-lib 21:38:12 boden: you are up again 21:38:17 hi.. I will try to make it quick 21:38:33 neutron-lib 1.27.0 is out, we are waiting on https://review.opendev.org/#/c/663141/. before we can consume in neutron 21:38:39 gate has been cranky 21:38:56 I'm sure it'll land before long 21:39:18 the only other thing I wanted to mention is to ask for help landing a bagpipe patch that's been sitting https://review.opendev.org/#/c/659881/ 21:39:41 small patch, so hopefully not too painfull 21:40:02 and that's all, unless others have comments 21:40:09 * mlavalle will look at it at the end of the meeting 21:41:07 ok, let's move on 21:41:15 #topic On demand agenda 21:41:32 haleyb: you have a topic 21:42:04 yes, but just a quick note that i will be tagging the stable branches today/tomorrow, just waiting for one patch to land 21:42:19 cool, thanks! 21:42:33 i wanted to talk about https://review.opendev.org/#/c/658414/ - Toward Convergence of ML2+OVS+DVR and OVN spec 21:42:51 i hope everyone has read it :) 21:43:57 thanks tidwellr for starting the discussion on it, and i've been updating with more data over the past week 21:44:32 it is starting to look good 21:44:55 as part of the next steps i wanted to propose we add an OVN job to the neutron check queue 21:45:24 it was proposed about two years ago and didn't get traction, but, well it's been two years and OVN has matured 21:45:47 I think we should do it 21:46:02 we will start non-voting, right? 21:46:13 i think it will help us get data on how stable it is when lots of patches are thrown at it 21:46:52 yes, it would be non-voting, but like other jobs, if it shows stability over some time (a month ?) we could propose making it voting 21:47:06 sounds good to me 21:47:12 what do others think? 21:47:25 the one thing i hadn't thought about is what job/jobs 21:47:42 sounds good, we can track it in the CI meeting 21:47:42 I think it's a good data point to have as we pursue this spec 21:48:01 njohnston: yue read my mind 21:49:24 so let's do it 21:49:36 are we done with the topic? 21:50:09 my only open question is what job? 21:50:18 tempest perhaps? 21:50:20 you mean from OVN? 21:50:40 right 21:50:40 let's shoot high... a scenario job? 21:51:53 sure 21:52:09 ok 21:52:21 let's change topic 21:52:28 I have a question of my own 21:53:24 llet's say we send this query to the PI: 21:53:28 API: 21:53:53 curl -s -X GET http://localhost:9696/v2.0/network-ip-availabilities?network_id=85d60f9a-40a2-44a6-b6f7-ca414864058&network_id=..... 21:54:21 and say I have a 1000 network ids in the query 21:54:47 does anybody know if there is a limit as to how long the url can be? 21:56:34 google shows 2K assuming it's the same question, so just a guess 21:57:16 2k characters? 21:57:32 but apparently the RFC says there is no limit 21:57:47 https://tools.ietf.org/html/rfc2616 21:57:55 it's up to the server to enforce 21:58:29 sounds good 21:58:32 thanks! 21:58:39 Have a very nice week 21:58:45 thanks for attending 21:58:49 #endmeeting