21:01:11 <mestery> #startmeeting networking
21:01:11 <openstack> Meeting started Mon Mar  2 21:01:11 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:14 <openstack> The meeting name has been set to 'networking'
21:01:21 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:01:25 <salv-orlando> mestery: you should see it as a chance to pick new blood
21:01:26 <markmcclain> o/
21:01:29 <mestery> #topic Announcements
21:01:32 <mestery> salv-orlando: lol :)
21:01:42 <mestery> We continue our march towards Kilo-3!
21:01:47 <mestery> #info Feature Proposal Freeze: March 5
21:01:55 <mestery> #info Feature, String, and Dependency Freeze: March 19
21:01:58 <mestery> #info RCs: April 9-23
21:02:02 <mestery> #info Kilo release: April 30
21:02:07 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings
21:02:16 <mestery> I know I paste these each week, but does anyone have any questions on these dates?
21:02:47 <mestery> I should highlight that approved specs with no code by this Thursday will be out of Kilo unless they can get a FFE
21:02:59 <mestery> I know there are a fair number in this state having just looked at the LP page
21:03:08 <mestery> #link https://launchpad.net/neutron/+milestone/kilo-3
21:03:49 <mestery> OK, lets move on then.
21:03:56 <mestery> #topic Bugs
21:04:17 <mestery> enikanorov enikanorov__: Here?
21:04:26 * dougwig dons his cage suit.
21:04:26 <mestery> I have a bug to discuss anyways
21:04:27 <mestery> https://bugs.launchpad.net/neutron/+bug/1426543
21:04:28 <openstack> Launchpad bug 1426543 in neutron "Spike in DBDeadlock errors in update_floatingip_statuses since 2/27" [High,In progress] - Assigned to Kevin Benton (kevinbenton)
21:04:28 <enikanorov__> hi
21:04:39 <mestery> I know kevinbenton and armax have been working that, with plenty of reviews.
21:05:00 <mestery> enikanorov__: See ^^^ for what was a critical gate bug last week
21:05:31 <enikanorov__> yeah, seen that
21:05:39 <mestery> Also, this one: https://bugs.launchpad.net/neutron/+bug/1426397
21:05:41 <openstack> Launchpad bug 1426397 in neutron "tempest.scenario.test_network_v6.TestGettingAddress.test_slaac_from_os intermittently fails with MismatchError" [Undecided,New] - Assigned to Henry Gessau (gessau)
21:05:46 <mestery> HenryG is working a fix on the tempest side for that one
21:05:46 <kevinbenton> What was the question about it?
21:05:55 <mestery> kevinbenton: No question, just raising awareness :)
21:06:16 <kevinbenton> Oh okay :)
21:06:28 <enikanorov__> mestery: thanks for doing it for me ;)
21:06:33 <mestery> enikanorov__: lol ;)
21:06:37 <mestery> enikanorov__: Did I miss anything else?
21:06:54 <enikanorov__> nope. other critical gate issue is already fixed
21:07:02 <enikanorov__> (I mean the bug with func test)
21:07:08 <mestery> enikanorov__: Cool!
21:07:25 <mestery> Anyone else have a bug to discuss this week?
21:07:36 <enikanorov__> yes
21:07:57 <enikanorov__> there is that bug with db reties and corresponding patch
21:08:05 <enikanorov__> let me find a link
21:08:20 <enikanorov__> https://review.openstack.org/#/c/149261/
21:08:27 <enikanorov__> https://bugs.launchpad.net/neutron/+bug/1382064
21:08:28 <openstack> Launchpad bug 1382064 in neutron "Failure to allocate tunnel id when creating networks concurrently" [High,In progress] - Assigned to Eugene Nikanorov (enikanorov)
21:08:43 <enikanorov__> so is there a consensus that we want to go with retries?
21:08:51 <enikanorov__> i'm a bit tired of that neverlasting discussion
21:08:53 <enikanorov__> salv-orlando: ?
21:09:17 <salv-orlando> enikanorov__: data tell me we should do as afazekas says, in general
21:09:39 <kevinbenton> Maybe we should dedicate a summit session to it?
21:09:43 <salv-orlando> but since what I found out in data contrast with a general mandate against use of lock for updatre
21:10:00 <salv-orlando> I would say that for fixing that bug we should just make sure we retry with a different vni id
21:10:15 <mestery> salv-orlando: ++
21:10:16 <enikanorov__> salv-orlando: ok, cool
21:10:18 <markmcclain> ++
21:10:18 <femtox> sorry to interupt you guys
21:10:28 <enikanorov__> (i'll take everything going after 'but')
21:10:30 <enikanorov__> :-)
21:10:58 <femtox> but would really welcome your advice on how to setup devstack with neutron networking as a VM on virtualbox or VM Workstation
21:11:04 <enikanorov__> so right now the plan is to use the decorator from oslo.db 1.5.0
21:11:21 <mestery> femtox: CAn you jump over to #openstack-neutron?
21:11:26 <enikanorov__> femtox: #openstack-neutron
21:11:29 <mestery> femtox: This is the weekly neutron team meeting
21:12:05 <femtox> yes, will do thanks. sorry to break in mestery.
21:12:11 <mestery> femtox: No worries
21:12:13 <kevinbenton> salv-orlando: what do you mean it contrasts with the mandate against "lock for update"
21:12:26 <dougwig> i think he means 'select for update' and galleria.
21:12:30 <dougwig> galera.
21:12:46 <salv-orlando> kevinbenton: I mean that there is a general trend against replacing its usage with alternatives, such as queries which do update with a where
21:13:08 <salv-orlando> dougwig: galleria might be a name for a vpn software
21:13:18 <mestery> salv-orlando: Or a mall in Minnesota
21:13:22 <kevinbenton> salv-orlando: i thought we had to replace them because they were broken on galera clusters anyway?
21:13:27 <kevinbenton> salv-orlando: also evil deadlocks
21:13:48 <dougwig> salv-orlando, mestery: yeah, that was auto-correct, being it's usual self.
21:13:49 <salv-orlando> mestery: I think there are malls called Galleria every where in the world. There's one in Hatfield near my place too.
21:14:03 <mestery> lol
21:14:11 <banix> and one in NY
21:14:15 <enikanorov__> 'lock for update' gives false promise of serialization in case of gallera. that's one of the reasons
21:14:20 <enikanorov__> (after deadlocks)
21:14:20 <salv-orlando> kevinbenton: broken in the sense that they do not work as expected there
21:14:23 <dougwig> normally i try to throw things into the weeds.  this time was not my fault, i swear.  :)
21:14:43 <salv-orlando> write-intent locks are always enforced on the local node
21:14:56 <salv-orlando> they're not propagate on write-sets. Simply because that would not make any sense at all.
21:15:13 <enikanorov__> ok, thanks for your feedback
21:15:15 <salv-orlando> so the way galera reacts to a situation where you acquired a lock but you shouldn;t
21:15:23 <salv-orlando> is by triggering a deadlock error.
21:15:57 <salv-orlando> Therefore the argument is whether one should retry the transaction on deadlock or design algorithms which avoid the deadlock
21:16:10 <kevinbenton> salv-orlando: i see
21:16:15 <rossella_s> another problem is that the select for update lock doesn't work with postgres in HA
21:16:41 <rossella_s> I am seeing problems in production because of that
21:16:43 <kevinbenton> salv-orlando: shouldn't we try algorithms anyway since we have an abusive relationship with our currentl sql driver which we refuse to leave?
21:16:45 <enikanorov__> rossella_s: do you have such environment to test?
21:17:02 <kevinbenton> salv-orlando: we can't avoid the awful 60 seconds to timeout on a held lock
21:17:12 <enikanorov__> kevinbenton: that's what we're trying to do
21:17:15 <enikanorov__> hence retries
21:17:32 <salv-orlando> kevinbenton: that is another good point. But I am afraid that it is a point that here adds only white noise. May I suggest to have a discussion on the already open ML thread
21:17:36 <markmcclain> kevinbenton: well the abusive relationship is our creation :)
21:17:38 <rossella_s> enikanorov__ I don't have one available right now but I can create one. Anyway customers are reporting that kind of problem, I mean the lock simply is not locking anything and we get duplicate entry errors
21:17:52 <salv-orlando> kevinbenton: btw, the write set replication deadlock does not have the 50 second timeout
21:17:55 <salv-orlando> it's different
21:18:06 <salv-orlando> rossella_s: what's the failure mode?
21:18:33 <kevinbenton> salv-orlando: i know, but it's also a side effect of "lock for update". i'll take discussion offline
21:18:41 <enikanorov__> rossella_s: i'm curious because we usually test against galera single writer/multireader
21:19:09 <rossella_s> salv-orlando if you have 2 neutron servers they both try to write on the same table even if there's the select for update lock. So one gets the duplicate entry error
21:19:18 <salv-orlando> kevinbenton: you're right. The whole point of doing write intent locks is that we were too lazy and too afraid to impleent a minimal level of coordination in software
21:19:48 <salv-orlando> rossella_s: so that would be HA in active/active mode on pg_sql?
21:20:26 <rossella_s> salv-orlando drbd
21:21:20 <gongysh> sorry, what is the right way to replace 'select for update' in HA environment of both mysql and pg_sql?
21:21:42 <salv-orlando> rossella_s: thanks. I think the last time I used drbd my age still started with a '2'. I need to document a bit
21:21:55 <mestery> lol
21:21:59 <mestery> OK, shoudl we move this discussion to the ML now?
21:22:02 <salv-orlando> mestery: I think we're diverging a bit
21:22:04 <mestery> per salv-orlando's advice?
21:22:07 <kevinbenton> gongysh: by not using it :)
21:22:23 <gongysh> ok
21:22:27 <kevinbenton> gongysh: generally "UPDATE WHERE" statements have been popular
21:22:44 <enikanorov__> gongysh: there is no alternative. there is no serialization available for distributed dbs with multiwriter mode
21:22:58 <mestery> OK, I think we've exhausted the bugs discussion, lets move on in the agenda now.
21:23:17 <mestery> emagana isn't here so we'll skip our docs update for the week.
21:23:30 <mestery> #topic Plugin Decomposition Update
21:23:43 <mestery> armax isn't here, but I wanted to give folks a chance to ask questions in this slots, etc.
21:24:00 <mestery> Also, armax has a series of patches moving the documentation of the stauts of the effort into the neutron git repo
21:24:12 <mestery> I encourage folks to add to that (as Plumgrid and midokura have done) when decomposing
21:24:29 <dougwig> https://review.openstack.org/160109
21:24:37 <dougwig> ^^ doc for vendor decomp status
21:25:02 <mestery> dougwig: Nice! Thanks for the link
21:25:10 <mestery> #link https://review.openstack.org/160109
21:25:18 <mestery> OK, lets move on.
21:25:25 <mestery> #topic nova-network to neutron migration
21:25:28 <mestery> anteaya markmcclain: Anything this week?
21:26:26 <mestery> I'll take that as a likely no.
21:26:31 <markmcclain> nothing new to share
21:26:34 <mestery> Cool
21:26:41 <mestery> #topic LBaaS in Kilo: Update from the other side
21:26:44 <mestery> dougwig: You're on
21:26:54 <dougwig> let's see if i can bust the rate limiter...
21:26:57 <dougwig> so, we're shipping this lbaasv2 thing in kilo.
21:26:57 <dougwig> it has a new object model and TLS termination/offload support.
21:26:57 <dougwig> models, migrations, extension, plugin, basic ref driver, client/CLI, devstack (in-tree), and api docs have merged.
21:26:57 <dougwig> tempest tests (in-tree), TLS support, scalable-ish agent driver, and vendor drivers are in gerrit.
21:26:57 <dougwig> horizon support won't happen until Liberty, though we're also thinking of seeing if we can do it in-tree instead of in horizon.
21:26:57 <dougwig> we are beginning to assemble thoughts on next steps here:
21:26:58 <dougwig> https://etherpad.openstack.org/p/lbaas-vancouver-planning
21:26:58 <dougwig> we still need to bring the operators into that discussion as well.
21:26:59 <dougwig> any questions/additions/comments?
21:28:01 <dougwig> that's all i've got.
21:28:27 * mestery digests LBaaS
21:28:30 <markmcclain> awesome
21:28:36 <mestery> Nice work dougwig and team
21:29:17 <mestery> #topic VPNaaS
21:29:20 <mestery> pc_m: You're up!
21:29:27 <pc_m> Just four items to update folks on...
21:29:44 <pc_m> Plan is to have VPN discussions as part of Neutron on-demand topics
21:30:09 <pc_m> Strong Swan driver is out for review. Need reviewers: https://review.openstack.org/144391
21:30:24 <pc_m> Working on functional job for StrongSwan as well.
21:30:50 <mestery> pc_m: Is the plan to make StrongSwan the default in Kilo?
21:30:59 <pc_m> Started refactoring for VPN to remove dependency on L3 agent. First commit is out for review https://review.openstack.org/#/c/160179/
21:31:12 <dougwig> pc_m: so the vpnaas meeting is moving into the on-demand agenda as needed?
21:31:27 <pc_m> mestery: No, but we should in L and then start to deprecate OpenSwan.
21:31:43 <pc_m> OpenSwan is no longer packaged with Ubuntu (14.10+)
21:31:49 <pc_m> dougwig: yes
21:32:15 <pc_m> dougwig: Not much interest/participation in meetings for the past month or so.
21:32:39 <dougwig> we've been discussing something similar for lbaas after v2 ships.
21:32:40 <pc_m> Will work with Carl on the refactoring... I have a few questions.
21:32:48 <mestery> dougwig: ++
21:33:06 <pc_m> That's all I have, unless there are more Qs
21:33:12 <mestery> Thanks pc_m.
21:33:22 <pc_m> Sure. Please help on reviews...
21:33:31 <mestery> #topic Open Discussion
21:33:41 <blogan> at least trim down lbaas meetings (octavia, neutron-lbaas)
21:34:07 <mestery> blogan: You don't like all those meetings? :)
21:34:40 <blogan> thats a trick question, as i am currently in a meeting
21:35:25 <mestery> OK, thanks for attending this week folks!
21:35:31 <dougwig> bye
21:35:37 <Sukhdev> thanks and bye
21:35:37 <mestery> Remember FPF is this Thursday.
21:35:38 <blogan> bye
21:35:40 <mestery> So get those patches out there!
21:35:41 <mestery> #endmeeting