16:01:47 #startmeeting networking_ml2 16:01:48 Meeting started Wed Jun 22 16:01:47 2016 UTC and is due to finish in 60 minutes. The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:52 The meeting name has been set to 'networking_ml2' 16:01:54 hi 16:02:03 #topic: Agenda 16:02:10 #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_June_22.2C_2016 16:02:38 We could not cover the full agenda last week - so, I brought it forward this week 16:02:57 anybody wants to add anything to it? 16:03:25 I can provide a quick update on the "unify portbinding stuff" 16:03:31 not much 16:03:43 andreas_s_ : sure 16:03:50 hi 16:04:29 #topic: Announcements 16:05:01 Ironic mid-cycle sprint is going on this week - if anybody cares 16:05:22 neutron mid-cycle is planned in middle of July in Ireland 16:06:11 anybody has anything else to share with team? 16:06:57 OK - lets move along then 16:07:09 #topic: Update on unified binding 16:07:21 andreas_s_ : please go ahead 16:07:37 sure 16:07:53 talked to rossella_s and ihar regarding ovo 16:08:02 the new binding_result object should be implemented as ovo 16:08:10 that's what I'm currently trying to figure out 16:08:23 if we get it release in Newton, there's no problem with upgrades 16:08:37 things like writing to 2 tables in parralell 16:09:01 this probably will come with Ocata first 16:09:16 and regarding the discussion with the patches of anilvenkata 16:09:22 we will continue in parallel 16:09:26 andreas_s_: what do you mean by “in parallel”? 16:09:40 Oh, the upgrade stuff, never mind 16:09:49 andreas_s_, there's not much overhead 16:09:56 sorry 16:10:05 not much conflicting stuff 16:10:25 and some core responded on his patchsets that its more important to get the router ha stuff fixed 16:10:28 andreas_s_ : I thought there was some overlap - based upon last week's discussion 16:10:52 Sukhdev, yes we somehow try to achieve something similar 16:11:31 at the moment there are not much conflicts 16:11:36 My plan had been to unify first, an generalize second, but doing this in reverse may be possible 16:11:39 those might come when I start touching the dvr pieces 16:11:56 but I'm far away from doing so at the moment 16:12:23 so what the other patches are doing is mostly renaming a table + renaming the corresponding objects and so on 16:12:35 there's not much logic or so being implemented 16:12:56 yes, and those patches are blocking for HA 16:13:14 and the db rename patch already has already a +2, so I'm confident that it will go in this week or so 16:14:09 #link: https://review.openstack.org/#/c/323993/ 16:14:09 that's it 16:14:34 so my next todo is the ovo stuff 16:14:36 If my -1 is still there, I can re-review if we have an agreement that anilvenkata’s patches make sense to merge before andreas_s_’s 16:15:05 rkukura, It's already gone... 16:15:10 due to a rebase 16:15:22 andreas_s_: ok, great, but will still try to re-review 16:15:23 or a minor change 16:15:33 rkukura, perfect! 16:15:38 commit message update 16:15:46 rkukura, please review 16:16:02 rkukura : I posted the link above - it looks good 16:16:11 ok, will try to get to it today 16:16:34 thanks 16:17:19 I'm done! Thanks! 16:17:55 Ok - I just gave a +1 as well 16:18:02 thanks 16:18:21 Anybody has anything else to discuss on this? 16:18:59 So, lets get back to the the items posted by routed network folks 16:19:21 the first item is https://review.openstack.org/#/c/320657/1/neutron/db/ipam_backend_mixin.py 16:20:21 There is a bit of discrepancy which causes tests to fail - 16:20:45 I looked at this last week and posted a comment to proceed with the merge - it has already merged 16:21:03 but, the question raised in the patch is valid for discussion here in this meeting 16:22:00 so, the issue is host Id being Null vs empty string 16:23:10 Any openions? 16:23:53 Seems like a simple bug fix to me. Are there any complications? 16:24:54 so this is on the db level? 16:25:02 only one question I have - this value is usually passed by external API - 16:25:21 and also internally used as well 16:27:09 https://review.openstack.org/#/c/181867/ 16:28:05 yamamoto, wow 16:28:08 i guess we can normalize it earlier. 16:29:24 yamamoto: right 16:30:27 I think similar fix should take care of it - as we can not control what senders send in API - it could be None or ' " 16:31:49 Sukhdev, so your're proposing to not change current behavior? 16:32:12 and add some code to the api layer to normalize it 16:32:21 andreas_s_ : yes 16:32:40 andreas_s_ : that makes it defensive coding 16:33:15 cool 16:34:40 I did not see https://review.openstack.org/#/c/181867/ - otherwise I would have proposed slightly different fix - 16:34:49 anyhow, moving right along - 16:35:07 #topic: Driver API feature requests 16:35:21 yamamoto : thanks for keeping track for this 16:35:59 i just happened to remember 16:36:08 first one is - https://bugs.launchpad.net/neutron/+bug/1273730 16:36:08 Launchpad bug 1273730 in neutron "MechanismDriverError hides original exception" [Low,In progress] - Assigned to Hong Hui Xiao (xiaohhui) 16:36:27 I looked at the patch proposed last week and posted comment - 16:36:47 #link: https://review.openstack.org/#/c/317358/5 16:37:22 Do you guys see this on your ML2 drivers as well? 16:37:57 I recall some discussion before of allowing subtypes of some exception to bubble up, but hiding random exceptions that might leak from an MD 16:38:49 rkukura : what do you mean by leak? 16:39:23 The original thinking was that any random exception might get raised internally by an MD, and that these should not be exposed to normal clients 16:39:50 they might give away unintended details about the deployment’s config, for example 16:40:14 So that’s why they get caught and replaced 16:41:10 rkukura : right, that was my understanding as well 16:41:29 but there was dicsussion at some point of allowing any exception derived from MechanismDriverError to be returned, so the driver can return specific exceptions if it wants to 16:42:27 So, with this patch - it will bubble up all of them 16:42:36 We actually did exactly this in GBP, which uses a similar model for its policy drivers 16:43:13 i wonder what to do for special exceptions like RetryRequest 16:43:58 fyi: I opened a bug report for the None vs. '' issue: https://bugs.launchpad.net/neutron/+bug/1595250 16:43:58 Launchpad bug 1595250 in neutron "ml2 Use None for portbinding.host instead of an empty String" [Undecided,New] 16:44:08 See https://github.com/openstack/group-based-policy/blob/master/gbpservice/neutron/services/grouppolicy/policy_driver_manager.py#L103 16:44:37 andreas_s_: thanks 16:44:40 hmm... yamamoto you mean have ML2 plugin retry an operation based upon the exception raised by MD? 16:44:51 andreas_s_ : cool - thanks 16:45:01 need to leave for today. See you next week 16:45:31 #link: https://bugs.launchpad.net/neutron/+bug/1595250 16:45:31 Launchpad bug 1595250 in neutron "ml2 Use None for portbinding.host instead of an empty String" [Undecided,New] 16:46:57 Sukhdev: not necessarily be ml2, but someone should handle those exceptions properly. 16:48:44 yamamoto : are you suggesting a separate bug to deal with that? 16:48:52 Sukhdev: I suggest we resolve the exception hiding bug similarly to what is done in the GBP code I linked, but allowing through any exception derived from MechanismDriverError, or maby even Neutron’s base exception, instead of GroupPolicyException (line 121) 16:49:55 Sukhdev: i'm just wondering at this point. but probaly it ought to be a separate bug. 16:50:42 rkukura : that is a good suggestion - they are looking for comments from ML2 guys - can you post the comment on the patch? 16:51:10 rkukura: does GBP have anything like db retry stuff? 16:51:41 sure 16:52:03 I’m not really sure about the DB retry 16:52:34 But I’m not sure that makes sense from inside an MD- wouldn’t this happen when the transaction around the precommit calls is committed? 16:52:50 what DB entry? - you mean the rollback? 16:54:22 * Sukhdev time check - 6 min 16:54:25 Sukhdev: I will suggest this on the patch 16:54:59 i meant RetryRequest DBDeadlock etc 16:55:10 rkukura : thanks - and, regarding your other concern, I think that is covered 16:56:40 yamamoto : oh I see - If memory serves me right, kevinbenton had done some work to deal with the DBDeadlock stuff a while back 16:57:11 yea, he made api layer handle those exceptions. 16:57:32 it means those exceptions need be propagated to api layer. 16:58:02 hmm... I see 16:58:08 So the question is whether these exceptions would be raised from within the ML2 MD, and need to be propogated to the API layer 16:58:20 replacing them with other exception as ml2 does would interfere the mechanism. 16:58:47 rkukura: right 16:58:50 But I think these exceptions get raised when the transaction is closed, which should be happening in ML2 itself, not in the MD 16:59:06 But I’m not certain about this 16:59:48 right - this might be worthwhile to look into in the context of this patch - or perhaps a new bug? 16:59:56 * Sukhdev time check 1 min 17:00:21 we could not get to the other three - perhaps we will continue in the next meeting 17:00:29 We are out of time - 17:00:47 Thanks for attending folks - great discussion 17:00:47 Thanks Sukhdev! 17:00:51 bye 17:00:54 bye 17:00:56 bye 17:01:00 #endmeeting