15:01:20 #startmeeting neutron_l3 15:01:22 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:25 The meeting name has been set to 'neutron_l3' 15:01:28 #topic Announcements 15:01:37 #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam 15:02:22 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 It looks like IPAM is set to go for Liberty. That is good. 15:03:48 yes, it is moved to liberty already - thanks for your +2 :) 15:04:36 johnbelamaric: I think it was already on its way but I thought I’d speak up anyway. :) 15:05:11 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 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 Any other announcements? 15:06:57 bp/report-ha-router-master is in the bag 15:07:07 amuller: nice! 15:07:25 my hair slowed down its decent into greyness 15:08:41 amuller: That is important. ;) 15:09:09 I actually don’t have much for today. So, I thought we could go in to an open agenda. 15:09:53 carl_baldwin: I wanted to discuss the possible approaches for IPAM 15:10:04 #topic neutron-ipam 15:10:04 I think a couple options came up 15:10:27 So, we have the current path we are on - Pavel is continuing that now 15:10:28 johnbelamaric: You have the floor. 15:10:53 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 johnbelamaric: Could you summarize the current path for the benefit of the meeting? 15:11:09 I wanted to know where folks stood on that 15:11:12 sure 15:12:24 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 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 the alternative is a more extensive refactor that will touch the plugins as well as the DB base 15:14:16 I would like to explore the alternative, just as an attempt 15:14:28 but I feel like I would be asking too much 15:14:38 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 carl_baldwin: yeah I'm still fighting these issues in the vmware plugin 15:15:22 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 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 carl_baldwin: yes, though salv-orlando mentioned on teh ML that he thought that issue will be resolved by oslo db 15:15:50 Does anyone see a disadvantage to taking a two-phased approach? 15:16:02 johnbelamaric: yes that is the systemic way 15:16:25 so that oslodb fix makes the current path viable, at least 15:16:29 if not the cleanest 15:16:40 johnbelamaric: salv-orlando: does this resolution by oslo db involve addressing the eventlet/mysql deadlock issues? 15:16:58 johnbelamaric: definetely not the cleanest. pavel_bondar has done a great job. But calling that clean is a bit too much ;) 15:17:17 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 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 replacing the mysql driver with a pure python one 15:17:56 salv-orlando: That makes sense. 15:18:03 that is aware of greenthreads 15:18:08 … and is what I was thinking. 15:18:23 carl_baldwin: still, if a transactions is long because it does 999 db operations, that's fine, it's understandable 15:18:46 but if a DB transaction is kept open for performing remote calls, that should be avoided 15:19:24 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 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 anyway, I'm probably writing too much stuff which is of no use for this meeting 15:20:34 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 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 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 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 salv-orlando: yes, that was the original thinking in the spec and at the mid-cycle. 15:22:28 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 and then make a call together 15:22:59 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 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 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 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 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 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 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 Or plan is to update all plugins before Liberty? 15:28:30 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 So we would focus on ML2 and then can discuss whether we want to re-work the other plugins or not 15:29:11 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 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 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 johnbelamaric: Is there much code that could be refactored to reduce code duplication? 15:31:28 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 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 salv-orlando: We need to be sure that message is translated. ;) 15:32:24 salv-orlando: that would work 15:35:35 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 johnbelamaric: +1 15:37:08 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 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 because weekends for me never turn out as planned 15:39:25 salv-orlando: I hear you. ok, sounds like a plan. 15:40:10 Anything else to discuss? 15:40:35 carl_baldwin: i think i am all set 15:41:07 #topic Open Discussion 15:44:37 Thanks, all. 15:44:50 thanks. have a good weekend 15:45:02 Let’s get Kilo buttoned up and get a lot of good stuff planned for Liberty. 15:45:08 #endmeeting