15:01:02 <carl_baldwin> #startmeeting neutron_l3
15:01:03 <openstack> Meeting started Thu Mar 19 15:01:02 2015 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:07 <openstack> The meeting name has been set to 'neutron_l3'
15:01:15 <carl_baldwin> #topic Announcements
15:01:21 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:01:34 <carl_baldwin> Kilo-3 is today.
15:02:33 <carl_baldwin> #link https://launchpad.net/neutron/+milestone/kilo-3
15:02:47 <carl_baldwin> rc1 is already being planned.  I’m not sure when the date will be.
15:03:05 <carl_baldwin> #link https://launchpad.net/neutron/+milestone/kilo-rc1
15:03:27 <carl_baldwin> IPAM stuff has been moved to rc1.
15:04:23 <carl_baldwin> Also, IPv6 router support, report ha router master, and multiple ipv6 prefixes.
15:04:58 <carl_baldwin> Looks like release candidates begin on April 9th.  That is only 3 weeks away.
15:05:00 <carl_baldwin> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
15:05:06 <carl_baldwin> Any other announcements?
15:06:16 <carl_baldwin> #topic neutron-ipam
15:06:35 <carl_baldwin> pavel_bondar: salv-orlando: tidwellr: ping
15:06:45 <tidwellr> pong
15:06:52 <pavel_bondar> pong
15:06:56 <pavel_bondar> Looks like I hit serious issue with transactions during integration testing
15:07:06 <pavel_bondar> it may require changing interface
15:07:21 <salv-orlando> here
15:07:59 <salv-orlando> I spoke about this with pavel_bondar already. He has all the details for making the ipam driver work.
15:08:22 <carl_baldwin> pavel_bondar: Can you catch the rest of us up?
15:08:31 <pavel_bondar> ok
15:08:32 <pavel_bondar> IPAM Driver was expected to run in separate db transaction, so it fetch new session and create new db transaction.
15:08:48 <pavel_bondar> and it works fine in most cases
15:09:21 <pavel_bondar> but when some plugin wraps up for example create_port() with transaction, things are breaking
15:10:30 <pavel_bondar> so ipam driver code is executed inside of existing transaction and create new transaction.
15:11:11 <pavel_bondar> I have seen 1k test failures, most of them happened only when create_port is wrapped by transaction on higher level
15:11:58 <pavel_bondar> after I made small patch to pass context to ipam driver, test failures count decreased  to ~100 falures
15:12:08 <pavel_bondar> 10x decreasing
15:12:49 <salv-orlando> basically the issue is not with the double transaction itself, but with the wrapping mandated by the plugin!
15:12:58 <salv-orlando> pavel_bondar: that was the bit which was unclear to me
15:13:05 <carl_baldwin> pavel_bondar: Is that the proposed action to fix the problem?  Pass the context to IPAM and run it in the same transaction?
15:13:07 <salv-orlando> so the problem is inheritance
15:13:30 <salv-orlando> carl_baldwin: that's the only viable solution if we want to give pluggable ipam to all plugins... however
15:13:33 <pavel_bondar> carl_baldwin: yes, for now I see only this solution
15:13:43 <salv-orlando> it defies a bit the very reason for which we introduced the interface
15:14:18 <pavel_bondar> carl_baldwin: because each plugin and a lot of other stuff like floating ip creation wraps db_base method with higher level transaction
15:14:28 <salv-orlando> pavel_bondar, carl_baldwin: what if we say that plugin that wrap super() calls in a transaction are not compatible with pluggable ipam?
15:14:53 <pavel_bondar> carl_baldwin: so we already run inside of another transaction in most cases
15:15:28 <carl_baldwin> salv-orlando: “it defies a bit the very reason…”  That is what I was thinking.
15:16:05 <carl_baldwin> salv-orlando: What plugins are we talking about that do this wrapping?
15:16:50 <salv-orlando> carl_baldwin: I think in a way or another several... probably pavel_bondar has the whole list
15:17:05 <salv-orlando> but from my perspective we might be happy if it works for ml2
15:17:10 <salv-orlando> and I'm pretty sure ml2 is one of them
15:17:30 <salv-orlando> ml2 is even worse because it overrides some of the methods we've refactored
15:18:22 <salv-orlando> anyway, the conclusion between me and pavel_bondar was that I'd look at this too and seek if we have any viable alternative, like stating that ipam pluggable might be enabled only for some plugin which met certain conditions
15:18:33 <carl_baldwin> salv-orlando: I don’t think we can not be compatible with ML2.
15:18:42 <salv-orlando> and if you tried to enable it on a plugin which does not met these conditions things are likely to break
15:19:02 <salv-orlando> so I was going to try tonight to make at least ML2 compatible with pluggable IPAM and separate transactions
15:19:15 <salv-orlando> and then report on the mailing list
15:19:31 <pavel_bondar> yeah, ml2 indefinitely wraps create_ipam() code in higher-level transaction, and other 3 plugins I have checked do the same.
15:19:35 <salv-orlando> If I fail we'd have to consider doing as pavel_bondar suggests
15:19:54 <carl_baldwin> salv-orlando: that sounds like the right thing to do next.  I’d like to jump in and help out if I can but I don’t want to slow you down.
15:21:57 <carl_baldwin> salv-orlando: we’ll watch for your report.
15:22:57 <salv-orlando> carl_baldwin: I'm very good at slowing down by myself ;)
15:24:14 <carl_baldwin> salv-orlando: Another reason for me not to slow you down any more.  ;)
15:24:47 <carl_baldwin> pavel_bondar: What about the other 100 test failures.  Have you started to look in to those?
15:25:58 <pavel_bondar> carl_baldwin: part of them comes from floating_ip stuff, but I am just started with them for now, will continue investigation on them
15:26:57 <carl_baldwin> pavel_bondar: Good.  Keep us posted on your progress.  Is there anything I can help with?
15:28:17 <pavel_bondar> carl_baldwin: Sure will keep you posted about the progress. And that is it for me for now, so will continue digging with other tests
15:28:41 <carl_baldwin> pavel_bondar and salv-orlando:  Thank you.
15:28:48 <carl_baldwin> tidwellr: ping
15:28:54 <tidwellr> here
15:29:29 <carl_baldwin> tidwellr: Let me have one more look through https://review.openstack.org/#/c/148698/ .  Hopefully, we can kick it in today.
15:29:43 <carl_baldwin> tidwellr: I might need to get another devstack running and try it out with the client modificatinos.
15:29:52 <carl_baldwin> *modifications
15:30:27 <carl_baldwin> tidwellr: Has this one run through the new tempest tests?
15:30:43 <tidwellr> carl_baldwin: no, and it needs to
15:31:01 <tidwellr> that's my task for the day
15:32:16 <tidwellr> carl_baldwin: I've also done some iterations on https://review.openstack.org/#/c/157597, I don't see a corresponding client patch though
15:32:34 <tidwellr> may need to get that started
15:33:12 <tidwellr> and then https://review.openstack.org/#/c/165264 should be put through the meat grinder
15:33:27 <carl_baldwin> tidwellr: I’ll see if Zengfa has some time to work on the client.
15:34:01 <tidwellr> at this point I'm just turning patch sets in response to reviews, I've got some bandwidth
15:34:04 <carl_baldwin> tidwellr: Thanks for the reminder about the quota patch.  I haven’t looked at it yet and it looks like I’m not alone in that.  :(
15:36:37 <tidwellr> I feel like subnet allocation is close, but the reviews haven't really come in on quotas and allocation yet :)
15:37:07 <carl_baldwin> tidwellr: Will review today and encourage others to do the same.
15:38:05 <carl_baldwin> Anything else on IPAM?
15:39:19 <salv-orlando> not from me
15:39:24 <carl_baldwin> tidwellr: Zengfa tells me that subnet allocation is tested and added to the client as part of the existing patches.  We should confirm.
15:39:43 <tidwellr> ok, I'll check it out
15:41:01 <carl_baldwin> #topic Open Discussion
15:41:25 <amuller> https://review.openstack.org/#/q/status:open+branch:master+topic:bp/report-ha-router-master,n,z
15:41:27 <carl_baldwin> #action carl_baldwin needs to work on the agenda page.  It has gotten stale.
15:41:41 <amuller> report-ha-router-master had its heavy patches merged the last couple of days
15:42:02 <amuller> the rest of the patches are ready to be merged on my end
15:42:24 <carl_baldwin> amuller: I noticed that one on the rc1 page.  Let’s have a look at the remaining ones.  Thanks.
15:43:06 <amuller> yeah, kind of a shame, even if all of the patches get approved today, mestery cut K3 already
15:43:21 <amuller> so d/s QE won't get to test the feature off a K3 build
15:43:25 <mestery> amuller: Not cut yet, but cutting soon once ttx gets back
15:43:25 <amuller> QA*
15:43:34 <mestery> amuller: But I believe I moved it to RC1
15:43:38 <amuller> mestery: ack
15:43:43 <mestery> amuller: cool
15:43:52 <mestery> amulleri: Time just ran out on us
15:43:56 <mestery> for kilo-3 at least
15:44:20 <amuller> Understood
15:47:47 <carl_baldwin> Anyone giving thought to Liberty and beyond?  (Besides IPAM which we know has some work left to do)
15:48:04 <amuller> DVR + L3 HA integration pops to mind, but I am biased :)
15:50:23 <saggi1> carl_baldwin: Us at dragonflow hope to get something ready for liberty
15:50:43 <carl_baldwin> amuller: ack and I agree
15:51:41 <amuller> carl_baldwin: Have you heard from Jaume about BGP lately?
15:52:49 <carl_baldwin> amuller: I haven’t.  It is something I’d like to revive for Liberty.  I think there was a fair amount of work done on it.
15:52:56 <carl_baldwin> saggi1: Any more specifics?
15:53:37 <saggi1> https://launchpad.net/dragonflow
15:53:42 <saggi1> kind of competing with dvr
15:53:55 <saggi1> different approach. Using ovs rules instead of namespaces.
15:54:59 <carl_baldwin> I think I’d like to revise and trim down my blueprint on backing networks and combine that with BGP.
15:55:11 <saggi1> We don't have too much working. But the work on factoring out dvr is helping us integrate.
15:55:46 <carl_baldwin> saggi1: thanks for the link.
16:00:03 <carl_baldwin> I guess we’re out of time.  Thanks, all.
16:00:14 <carl_baldwin> #endmeeting