15:01:20 <carl_baldwin> #startmeeting neutron_l3
15:01:22 <openstack> Meeting started Thu Apr  2 15:01:20 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:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:25 <openstack> The meeting name has been set to 'neutron_l3'
15:01:28 <carl_baldwin> #topic Announcements
15:01:37 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:02:22 <carl_baldwin> I guess you’ve seen that the specs repository has been opened for Liberty.
15:02:33 * carl_baldwin almost wrote Kilo.  :|
15:03:10 <carl_baldwin> It looks like IPAM is set to go for Liberty.  That is good.
15:03:48 <johnbelamaric> yes, it is moved to liberty already - thanks for your +2 :)
15:04:36 <carl_baldwin> johnbelamaric: I think it was already on its way but I thought I’d speak up anyway.  :)
15:05:11 <carl_baldwin> For Kilo, we did get subnet allocation merged.  Also, the L3 agent restructuring scope defined for Kilo was completed in its entirety.
15:05:38 <carl_baldwin> I don’t plan any more major restructuring for a while.  That was a lot of effort by a number of us.
15:05:53 <carl_baldwin> Any other announcements?
15:06:57 <amuller> bp/report-ha-router-master is in the bag
15:07:07 <carl_baldwin> amuller: nice!
15:07:25 <amuller> my hair slowed down its decent into greyness
15:08:41 <carl_baldwin> amuller: That is important.  ;)
15:09:09 <carl_baldwin> I actually don’t have much for today.  So, I thought we could go in to an open agenda.
15:09:53 <johnbelamaric> carl_baldwin: I wanted to discuss the possible approaches for IPAM
15:10:04 <carl_baldwin> #topic neutron-ipam
15:10:04 <johnbelamaric> I think a couple options came up
15:10:27 <johnbelamaric> So, we have the current path we are on - Pavel is continuing that now
15:10:28 <carl_baldwin> johnbelamaric: You have the floor.
15:10:53 <johnbelamaric> But I understand there were some concerns about the desire for a more extensive refactor that will take the IPAM calls outside (before) the database transactions
15:11:08 <carl_baldwin> johnbelamaric: Could you summarize the current path for the benefit of the meeting?
15:11:09 <johnbelamaric> I wanted to know where folks stood on that
15:11:12 <johnbelamaric> sure
15:12:24 <johnbelamaric> We have refactored the DB base plugin to call out to the IPAM driver. However, because the subclasses actually start the transaction prior to call up the chain, we end up inside a DB transaction during the IPAM calls. This required us to pass the session down to the driver
15:13:01 <johnbelamaric> so the current path is to allow this to go forward as is, passing the context (or at least the session) own to the driver. this means there is not a complete separation of the layers
15:13:23 <johnbelamaric> the alternative is a more extensive refactor that will touch the plugins as well as the DB base
15:14:16 <salv-orlando> I would like to explore the alternative, just as an attempt
15:14:28 <salv-orlando> but I feel like I would be asking too much
15:14:38 <carl_baldwin> johnbelamaric: Right, past experience — as salv-orlando may be able to provide more insight — seems to show that going to an external system inside a transaction can cause issues.
15:15:07 <salv-orlando> carl_baldwin: yeah I'm still fighting these issues in the vmware plugin
15:15:22 <johnbelamaric> salv-orlando: well, my thinking right now is to pursue both paths - and we (infoblox) can provide some help to make that attempt at least
15:15:41 <salv-orlando> on one side there's an eventlet issue, which will be fixed in a "systemic" way, on the other side long transactions should be avoided when possible
15:15:46 <johnbelamaric> carl_baldwin: yes, though salv-orlando mentioned on teh ML that he thought that issue will be resolved by oslo db
15:15:50 <carl_baldwin> Does anyone see a disadvantage to taking a two-phased approach?
15:16:02 <salv-orlando> johnbelamaric: yes that is the systemic way
15:16:25 <johnbelamaric> so that oslodb fix makes the current path viable, at least
15:16:29 <johnbelamaric> if not the cleanest
15:16:40 <carl_baldwin> johnbelamaric: salv-orlando:  does this resolution by oslo db involve addressing the eventlet/mysql deadlock issues?
15:16:58 <salv-orlando> johnbelamaric: definetely not the cleanest. pavel_bondar has done a great job. But calling that clean is a bit too much ;)
15:17:17 <johnbelamaric> my thinking of doing both paths is really to help ensure the acceptance by the larger community - I want to make sure that at least on of these things merges :)
15:17:40 <salv-orlando> carl_baldwin: yes. Basically it's not even at the oslo-db level, I think the solution is at the lowest level in the "db stack"
15:17:53 <salv-orlando> replacing the mysql driver with a pure python one
15:17:56 <carl_baldwin> salv-orlando: That makes sense.
15:18:03 <salv-orlando> that is aware of greenthreads
15:18:08 <carl_baldwin> … and is what I was thinking.
15:18:23 <salv-orlando> carl_baldwin: still, if a transactions is long because it does 999 db operations, that's fine, it's understandable
15:18:46 <salv-orlando> but if a DB transaction is kept open for performing remote calls, that should be avoided
15:19:24 <salv-orlando> initially we have been leveraging this anti-pattern because it provided a quick and easy way to abort the DB operation on backend failures.
15:20:04 <salv-orlando> on the other hand, as pavel_bondar's work proves, this is not enough to achieve a consistent system, you still need to rollback on the backend
15:20:27 <salv-orlando> anyway, I'm probably writing too much stuff which is of no use for this meeting
15:20:34 <carl_baldwin> salv-orlando: I agree with you.  I’m a fan of fixing the db greenthread thing regardless of its impact on this and I agree it won’t give us license to keep transactions open arbitrarily.
15:20:52 <johnbelamaric> salv-orlando: yes, and even that is risky because other users of the external system may also need the thing you are rolling back the create of - that is, it's not a distributed transaction so there are race conditions anyway you cut it
15:21:32 <salv-orlando> basically, I believe that the work from pavel_bondar can be easily transformed into an IPAM integration library, which will be used in a composition fashion by plugins.
15:22:07 <carl_baldwin> I tend to think that we need to design it to fail in the best way possible and then provide some way to clean up artifacts that remain, either on-demand or periodically.
15:22:12 <johnbelamaric> salv-orlando: yes, that was the original thinking in the spec and at the mid-cycle.
15:22:28 <salv-orlando> this means that the code however won't be in db_base_plugin_v2. Rather than providing both solutions and merging them (I expect pushback on that), I would spend next week trying to see how achievable is that.
15:22:31 <salv-orlando> and then make a call together
15:22:59 <salv-orlando> a two-phased approach where we first merge code in one way and then take it out of db_base_plugin sounds like unnecessary effort on our side.
15:23:15 <johnbelamaric> salv-orlando: ok. i didn't expect both solutions to merge, just one of the two. but I want to make sure something merges. I am concerned about pushback if many plugins need changes.
15:23:53 <johnbelamaric> salv-orlando: so I am thinking we try out the bigger refactor in parallel to see how viable it is (as you say)
15:24:50 <johnbelamaric> salv-orlando: but we have the fallback to the current plan if it is too much change/risk for the larger refactor
15:27:05 <johnbelamaric> there is also the question of the "switch" to use the old code path or to use the pluggable code path. as i understood it that was not looked upon very well by the larger neutron team.
15:27:26 <pavel_bondar> If we are implementing IPAM on plugin level, we will still have two path with new IPAM for updated plugins and with old ipam for non-updated one. So two path will present in Liberty too?
15:27:30 <johnbelamaric> I suppose if plugins use the composition path then they never call the super method on the db plugin so that the switch isn't needed
15:28:00 <pavel_bondar> Or plan is to update all plugins before Liberty?
15:28:30 <johnbelamaric> pavel_bondar: I think the idea would be that plugins can update to use the pluggable IPAM via composition, or they can continue to call super and get the existing IPAM
15:29:02 <johnbelamaric> So we would focus on ML2 and then can discuss whether we want to re-work the other plugins or not
15:29:11 <carl_baldwin> I think it will be difficult to require all plugins to move.  Especially with the move to get plugin code out of tree.
15:29:57 <johnbelamaric> carl_baldwin: yes, if it's out-of-tree then there is little hope for moving all. so, I think we leave the old path - but that leaves a lot of old crufty code around until everyone moves to the newer version
15:30:55 <salv-orlando> the call to super does not do exclusively IPAM. But you can call it with a param that says - please don't do IPAM, I already have sorted it out
15:30:57 <carl_baldwin> johnbelamaric: Is there much code that could be refactored to reduce code duplication?
15:31:28 <salv-orlando> and the base class will reply: "sure thing, sir. It is a shame you do not use anymore our IPAM services, but I hear they will be deprecated anyway"
15:32:09 <johnbelamaric> carl_baldwin: possibly some of it could be changed to call out to a common routine with reference driver. salv-orlando probably has a better sense of it than I do
15:32:18 <carl_baldwin> salv-orlando: We need to be sure that message is translated.  ;)
15:32:24 <johnbelamaric> salv-orlando: that would work
15:35:35 <johnbelamaric> so, it sounds like we want to take a crack at the larger refactor and at least see what it will take
15:35:49 <carl_baldwin> johnbelamaric: +1
15:37:08 <johnbelamaric> salv-orlando: I think you mentioned you wanted to do this, but I can take a look at it next week if you want instead
15:38:52 <salv-orlando> johnbelamaric: I think I will have a crack at it over the weekend. But if you do not see anything by next tuesday, go ahead
15:39:03 <salv-orlando> because weekends for me never turn out as planned
15:39:25 <johnbelamaric> salv-orlando: I hear you. ok, sounds like a plan.
15:40:10 <carl_baldwin> Anything else to discuss?
15:40:35 <johnbelamaric> carl_baldwin: i think i am all set
15:41:07 <carl_baldwin> #topic Open Discussion
15:44:37 <carl_baldwin> Thanks, all.
15:44:50 <johnbelamaric> thanks. have a good weekend
15:45:02 <carl_baldwin> Let’s get Kilo buttoned up and get a lot of good stuff planned for Liberty.
15:45:08 <carl_baldwin> #endmeeting