14:00:35 <mestery> #startmeeting networking
14:00:36 <openstack> Meeting started Tue Apr  7 14:00:35 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:40 <openstack> The meeting name has been set to 'networking'
14:00:47 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:00:55 <mestery> #topic Announcements
14:01:15 <mestery> #info We'll be cutting the Kilo RC on Thursday at this point, barring any bugs which lapse into Friday from the RC1 list.
14:01:22 <mestery> #link https://launchpad.net/neutron/+milestone/kilo-rc1
14:01:27 <sc68cal> o/
14:01:28 <mestery> We'll cover the RC1 bugs after announcements
14:01:43 <mestery> #info Neutron mid-cycle set for June 24-26 in Fort Collins, CO
14:01:45 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/060713.html
14:02:26 <mestery> The RC is the main focus right now, so lets jump into the RC bugs before continuing with the rest of the agenda.
14:02:35 <mestery> #topic Kilo RC Bug Scrub
14:02:37 <mestery> The link again:
14:02:38 <mestery> #link https://launchpad.net/neutron/+milestone/kilo-rc1
14:02:47 <mestery> #link https://bugs.launchpad.net/bugs/1434667
14:02:49 <openstack> Launchpad bug 1434667 in neutron "VLAN transparent feature cleanup" [Critical,In progress] - Assigned to pritesh (pritesh)
14:03:20 <mestery> amotoki: Looks like you're good with this one so far, pending Jenkins.
14:03:36 <amotoki> mestery: yes
14:03:47 <mestery> pritesh has been iterating on it, so I think this one looks to be in good shape.
14:03:53 <mestery> amotoki: thanks!
14:04:03 <amotoki> some discussion point related to ml2 plugins is remaining but we can address separately
14:04:05 <salv-orlando> amotoki: did pritesh remove the config option at the end?
14:04:35 <amotoki> salv-orlando: no so far. I think we can remove in a follow-up patch.
14:04:53 <salv-orlando> if that's ok for you it works for me... if pritesh won't do that,  I will ;)
14:04:59 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1438969
14:05:00 <openstack> Launchpad bug 1438969 in neutron "Newly created DVR router as a result of new VM does not get ARP neighbors update, new VM has no connectivity" [Critical,In progress] - Assigned to Armando Migliaccio (armando-migliaccio)
14:05:07 <HenryG> pritesh is being very responsive so he could do it today I am sure
14:05:15 <mestery> I know armax took this one over and was working on some tests for this one yet
14:05:35 <mestery> I'll ping armax when he wakes up later :)
14:05:40 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1440183
14:05:41 <openstack> Launchpad bug 1440183 in neutron "DBDeadlock on subnet allocation" [Critical,In progress] - Assigned to Dane LeBlanc (leblancd)
14:05:45 <mestery> dane_leblanc: How is this one coming?
14:05:55 <salv-orlando> mestery: this is the one where I'm being a pita
14:05:57 <dane_leblanc> mestery: I've got 2 patches out for review
14:06:03 <mestery> lol
14:06:06 <mestery> I know enikanorov also was looking at this one.
14:06:10 <mestery> salv-orlando: Can you explain more?
14:06:15 <mestery> Do you have concerns on the approach being taken?
14:06:22 <dane_leblanc> mestery: Either seems to fix the problem, not sure if we want both merged.
14:06:23 <enikanorov_> dane_leblanc: right now the patch only fixes single worker case
14:06:39 <enikanorov_> dane_leblanc: do you think it would be too different to add retrying logic there?
14:06:54 <enikanorov_> the concern is that nobody uses neutron in single worker mode
14:07:01 <salv-orlando> nope... it's just that a catch on DBReferenceError appeared, but it's not clear exactly how a concurrent allocation might cause that. I am simply looking for a clarification
14:07:15 <mestery> salv-orlando: Ack
14:07:37 <enikanorov_> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOiBcIihJbnRlZ3JpdHlFcnJvcikgaW5zZXJ0IG9yIHVwZGF0ZSBvbiB0YWJsZSBcXFwiaXBhbGxvY2F0aW9uc1xcXCJcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiODY0MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDI4NDE0ODE5NzczfQ==
14:07:39 <salv-orlando> I pointed that out in the review, and eventually I'll find 30 minutes to look at the logs myself
14:07:43 <dane_leblanc> enikanorov: Retrying will help the multi neutron node?
14:07:45 <enikanorov_> just another manifestation of the issue
14:08:01 <enikanorov_> dane_leblanc: look at IntegrityError by the link above
14:08:09 <salv-orlando> I'm not sure how many bugs there are there then
14:08:17 <enikanorov_> your solution would fix that for single server, but for multuiple servers it will not work
14:08:40 <salv-orlando> because I followed the discussion and the fingers was pointed against the lock wait timeout issue, now enikanorov_ is suggesting there is also a genuine concurrency issue?
14:09:00 <enikanorov_> salv-orlando: i'm surprised too :)
14:09:05 <salv-orlando> sorry, by "lock wait timeout" I meant "the funny eventlet thing"
14:09:15 <dane_leblanc> salv-orlando: Yes. For some reason, the previous delete transaction finished...
14:09:22 <enikanorov_> salv-orlando: btw, its postgres, so no eventlet issues
14:09:39 <dane_leblanc> but the next create-subnet transaction is finding an entry in the port table
14:09:42 <enikanorov_> its postgres - i mean failure with IntegrityError
14:10:23 <dane_leblanc> An entry that should be deleted at that point.
14:10:28 <salv-orlando> enikanorov_: thanks. So it could actually be a dirty read
14:10:44 <salv-orlando> (if it happens only with postgres)
14:11:04 <enikanorov_> it's usual race with allocation imo
14:11:58 <salv-orlando> I start to understand now. The follow up question however is... what is the greenthread lock protecting us against?
14:12:19 <enikanorov_> it's protecting us against correct solution :)
14:12:38 <salv-orlando> anyway, mestery is probably hating us for wasting precious meeting time. I guess we can sort this out by the end of the day.
14:12:39 <mestery> lol
14:12:54 <salv-orlando> on gerrit and openstack-neutron
14:12:56 <mestery> salv-orlando: It's not a problem, the RC is the main thing and this bug is targeted there :)
14:13:05 <mestery> But yes, gerrit and #openstack-neutron seem appropriate now.
14:13:09 <mestery> So, lets move on to th next bug
14:13:22 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1274034
14:13:24 <openstack> Launchpad bug 1274034 in neutron "Neutron firewall anti-spoofing does not prevent ARP poisoning" [High,In progress] - Assigned to Kevin Benton (kevinbenton)
14:13:33 <mestery> kevinbenton has a potential arp poisining fix using OVS
14:13:47 <mestery> I'm not sure we'll block the release on this, but for now, his fix is elegant enough it's worth looking at
14:13:56 <mestery> yamamoto has already reviewed this (thanks!) I know
14:14:08 <mestery> #link https://review.openstack.org/171003
14:14:33 <salv-orlando> mestery you actually used hackish and elegant in the same sentence!?!
14:14:45 <mestery> lol
14:15:15 <mestery> kevinbenton is keen on seeing a fix for this in Kilo, so lets see what we can do today
14:15:23 <mestery> Next up
14:15:24 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1438329
14:15:26 <openstack> Launchpad bug 1438329 in neutron "Example configuration files lack changes for Kilo" [High,In progress] - Assigned to Edgar Magana (emagana)
14:15:37 <mestery> emagana has proposed a change to update our neutron.conf file which was out of date a bit
14:15:53 <mestery> In Liberty, we should move to auto-generating this like nova does, but for now, this is the fix we have
14:16:03 <mestery> #link https://review.openstack.org/171059
14:16:07 <mestery> Please review and provide feedback
14:16:29 <mestery> Next up
14:16:35 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1439817
14:16:36 <openstack> Launchpad bug 1439817 in neutron "IP set full error in kernel log" [High,In progress] - Assigned to Brian Haley (brian-haley)
14:16:45 <mestery> This one is in the merge queue, thanks to haleyb for grabbing it by the horns and driving it to completion!
14:17:11 <mestery> And finally we have this one
14:17:12 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1440824
14:17:14 <openstack> Launchpad bug 1440824 in neutron "Restricting shell scripts to sh only kills productivity" [High,In progress] - Assigned to Maru Newby (maru)
14:17:19 <mestery> marun: Did you want to discuss this one here now?
14:17:24 <mestery> I know you put it on the agenda for later
14:17:35 <mestery> But lets cover it here if you're ok with that.
14:17:41 <marun> Is yamamoto here to advocate for non-bash?
14:17:49 <mestery> I saw him earlier, yes.
14:17:54 <yamamoto> marun: hi
14:17:54 <marun> Or is there anyone else that thinks we should be restricting outselves to sh?
14:17:59 <marun> yamamoto: hi
14:18:16 <marun> yamamoto: I've been adding a lot of bash scripts lately.
14:18:16 <ihrachyshka> if it's dev only, go safely with bash
14:18:23 <marun> yamamoto: They are dev only, yes
14:18:27 <salv-orlando> I am ok with maru's proposal.
14:18:34 <marun> yamamoto: Is the concern with non-dev bash scripts?
14:18:35 <mestery> ++ to marun's proposal
14:18:55 <yamamoto> marun: bash makes my life a little harder but it won't kill me
14:19:25 <ihrachyshka> bash is not the worst test dep we have after all
14:19:29 <mestery> OK, so I tihnk we have agreement to merge that patch marun.
14:19:32 <ihrachyshka> test -> dev
14:19:37 <marun> ok
14:19:42 <markmcclain> devstack requires bash, so there's already a clear precedence for it in dev envs
14:19:43 <mestery> #agreed We'll move forward with allowing bash scripts
14:20:03 <HenryG> yay
14:20:15 <mestery> OK, we made it through the RC bugs.
14:20:27 <mestery> If anyone finds a new blocking bug in the next few days, please reach out and let me know.
14:20:39 <mestery> I'm not saying we'll have an RC2, but our history indicates we may
14:20:47 <salv-orlando> mestery: I did not see any blocking bug. We've move all core api changes to extension, so I guess we're good
14:20:58 <mestery> salv-orlando: Ack, and thanks!
14:21:00 <salv-orlando> The only remark is that subnet pools are a "mock extension"
14:21:12 <mestery> I had gone through and scrubbed all critical/high bugs a few weeks back as well
14:21:22 <salv-orlando> meaning that even if they're not marked as supported, the API resources are still there. Is anyone annoyed by that?
14:21:33 <salv-orlando> If yes, we can sort that out with a quick patch.
14:22:29 <amotoki> i am okay with it. most plugins consume subnet impl from db plugin.
14:22:35 <mestery> salv-orlando: Did you want to propose the quick patch and we can review in gerrit? Or it's not even worth it if no one complains?
14:22:58 <salv-orlando> for what amotoki said we're talking about 1 plugin only (of the known ones)
14:23:16 <salv-orlando> then I cannot speak for other off-tree plugins of which we are not aware
14:23:23 <mestery> OK
14:23:56 <mestery> OK, lets move on now.
14:24:35 <mestery> Lets skip bugs/docs today in interest of keeping the meeting short to focus on the RC
14:24:36 <mestery> #topic Open Discussion
14:24:43 <mestery> #link https://etherpad.openstack.org/p/liberty-neutron-summit-topics
14:24:48 <mestery> Liberty Summit etherpad link ^^^
14:24:59 <mestery> We'll begin digging into that in earnest next week once the RC is out
14:25:06 <mestery> Please continue posting ideas there though
14:26:14 <mestery> OK, thanks everyone, lets keep the focus on the RC bugs for the next two days.
14:26:23 <mestery> Kilo is almost baked, lets make sure it smells good too. ;)
14:26:29 <mestery> See you all next week and on IRC/ML!
14:26:35 <mestery> #endmeeting