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