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