16:01:02 <Sukhdev> #startmeeting networking_ml2
16:01:02 <openstack> Meeting started Wed Dec  9 16:01:02 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:06 <openstack> The meeting name has been set to 'networking_ml2'
16:01:21 <yalie> hi
16:01:25 <sc68cal> o/
16:01:29 <Sukhdev> #topic: Agenda
16:01:37 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_December_9.2C_2015
16:02:02 <Sukhdev> Welcome to this week's meeting. Anybody would like to add anything to the agenda?
16:02:22 <Sukhdev> #topic: Announcements
16:02:43 <Sukhdev> I have do not have much other than the fact that I will be gone next three weeks
16:03:07 <Sukhdev> rkukura : are you around for next three weeks?
16:03:44 <rkukura> I’m available to chair thr next two weeks, but gone on 12/30.
16:03:59 <Sukhdev> good -
16:04:19 <Sukhdev> maybe we can cancel the last meeting of the year :-)
16:04:28 <rkukura> Should we plan to meet 12/23, or skip that too?
16:04:58 <Sukhdev> I will be gone - perhaps you can ask next week from the participants
16:05:01 <rkukura> Lets see next week who will be available on 12/23.
16:05:12 <Sukhdev> good idea
16:05:14 <rkukura> same
16:05:25 <Sukhdev> Any body else has any announcement?
16:05:40 <Sukhdev> Lets dive into the agenda
16:05:58 <Sukhdev> #topic: Driver API for security groups
16:06:07 <Sukhdev> yamamoto is here -
16:06:19 <Sukhdev> yamamoto : would you want to provide update?
16:06:20 <yamamoto> hi
16:06:59 <yamamoto> i was not following it for a while and am catching up
16:07:05 <yamamoto> so no updates from me
16:07:34 <rkukura> I think yalie is here
16:08:06 <Sukhdev> I saw updates on the patch -
16:08:16 <Sukhdev> yalie : are you here?
16:08:16 <yalie> yamamoto: I will update it based your comments
16:08:16 <yalie> yamamoto: the proposal need be polished.
16:08:25 <yalie> Sukhdev: yes
16:08:30 <rkukura> I have not yet given the current version a careful review, but like that it is addressing enforcement of the SGs in port binding
16:08:50 <yalie> Sukhdev: now the patch only focus on enforcement
16:09:01 <rkukura> I’d like to see the scheme for this work with extension drivers to similarly enforce the semantics of any extension.
16:09:11 <yalie> rkukura: thanks
16:09:33 <yalie> rkukura: yes, that's the direction.
16:09:45 <Sukhdev> yalie : is this work planned for Mitaka?
16:09:46 <rkukura> yalie: What is the consensus regarding adding precommit/postcommit for SG APIs? Not needed?
16:10:11 <yalie> rkukura: and the security group precommit slip into another patch
16:10:21 <yalie> https://review.openstack.org/#/c/252755/
16:11:30 <rkukura> yalie: Hadn’t seen that. So are the precommit events within the DB transactions?
16:11:36 <yalie> Sukhdev: I think yes, but not sure if the time could catch up.
16:11:36 <yalie> rkukura: the consensus is re-use the callback logic
16:12:12 <yalie> rkukura: yes, add the new event like BEFORE_CREATE, and put it into the same db transactions.
16:12:46 <pc_m> yalie: Seems like there are two ways, callbacks or pre/post commit. Is the current implementation using callbacks?
16:12:47 <yalie> rkukura: it re-use the current call back logic.
16:12:48 <rkukura> yalie: So raising an exception from PRECOMMIT will rollback the TX and return that exception to the user?
16:13:22 <yalie> pc_m: yes
16:13:33 <yalie> rkukura: yes, now it reture to user directly.
16:13:36 <pc_m> yalie: Is the intent to continue w/callbacks, switch to pre/post commit, or use some combination?
16:13:54 <rkukura> I’d like to make sure that if an ML2 MD can only partially implement SG semantics, it can reject updates to the SGs that it is responsible for enforcing on bound ports if the new rule cannot be enforced.
16:14:45 <yalie> pc_m: we wish to use ML2 precommit mech, and it's a long term disscusion.
16:15:49 <rkukura> yalie: Does the callback mechanism give you the before and after attribute values so the driver can see what has changed?
16:16:39 <yalie> rkukura: I need think more about it
16:17:01 <yalie> rkukura: yes, it also works.
16:17:12 <pc_m> rkukura: with callback mech, you can pass other args to the notify.
16:18:03 <Sukhdev> How can an MD reject the updates by using callbacks?
16:18:09 <yalie> rkukura: but it could not benifit from later status sync in ML2 mech driver, if there is .
16:21:04 <rkukura> yalie: Agreed on the status sync, but that is mostly postcommit, and I’m convinced the current/previous values don’t make sense in sync approaches that always sync to the current state. I think the precommit validating updates is where comparing current to previous would possible be needed, but I’m not sure.
16:21:06 <pc_m> Sukhdev: the callback can raise exception. I guess it could be caught?
16:21:25 <yalie> I am not sure.
16:21:58 <Sukhdev> While callback mechanism will provide the way for the MD's to act on the change in SG, how do the rejection gets passed back to the user?
16:24:25 <yalie> callback only loop the registered md driver functions.
16:24:53 <yalie> it's still in sg db
16:25:24 <Sukhdev> i see
16:25:25 <pc_m> yalie: doesn't it collect all exceptions from notified components and provide the info in a list as result?
16:25:35 <pc_m> it == callback
16:27:02 <Sukhdev> yalie : once the proposal is firmed up - let me know if I can help. I have an interest in this feature and wanted to wait for the outcome of the discussions
16:27:22 <pc_m> callback notify catches each callback exception and appends to a list.
16:27:26 <yalie> and could catch the exception ?
16:27:26 <yalie> Sukhdev: do you mean get the result from MD operation?
16:27:26 <yalie> Sukhdev: MD driver would have another journal thead the get the db update from callback, and sent to controller outside.
16:27:26 <yalie> Sukhdev: but the result is not sync.
16:27:29 <Sukhdev> I can help with the implementation and testing ,etc
16:27:53 <yalie> pc_m: great point, I htink now callbakc will only return when it get exception.
16:28:08 <yalie> Sukhdev: thanks! Sukhdev!
16:28:37 <pc_m> yalie: Callback returns None or exception, which can pass back info.
16:28:55 <pc_m> yalie: I'm interested as well in this, so can try to help as well.
16:29:22 <yalie> pc_m: thanks, pc_m!
16:29:39 <yalie> pc_m: do you mean callback need be updated?
16:30:49 <yalie> pc_m: to catch up exception list from all the MD methods?
16:30:53 <pc_m> yalie: Wehn event occurs, notifier calls all subscribers' callback methods. Those method's return result is ignored by notifier, but the notifier will collect all exception info.
16:31:50 <yalie> pc_m: ok, I will check it.
16:32:23 <pc_m> yalie: https://github.com/openstack/neutron/blob/master/neutron/callbacks/manager.py#L138-L149
16:32:33 <pc_m> yalie: Can discuss offline, if you want.
16:33:14 <Sukhdev> In the interest of time - lets move on
16:33:33 <Sukhdev> #topic: Driver status coalescing/visibility
16:34:08 <Sukhdev> i thought I saw yamahata here -
16:34:36 <yalie> pc_m: yes, of cause, thank you
16:34:45 <Sukhdev> If no body is here, lets skip and move on to the next item
16:34:49 <yalie> rkukura: I will discuss with you about the enforcement offline
16:34:59 <rkukura> yalie: great!
16:35:11 <yalie> rkukura: thanks!
16:35:29 <Sukhdev> yalie : you mean on the ML or IRC channel ?
16:35:42 <Sukhdev> yalie : please pull me into the discussion as well
16:36:23 <Sukhdev> shall we move on?
16:36:45 <yalie> Sukhdev: I mean IRC channel, of cause we need disscuss toghter, and yamamoto :)
16:37:16 <Sukhdev> yalie : I am available after this meeting - we can move to neutron channel
16:37:33 <rkukura> I ran into John Joyce last week, but unfortunately didn’t think to ask him about any progress on driver status coallescing.
16:37:52 <rkukura> Sukhdev, yalie: I will not be available after this meeting for a few hours
16:38:15 <yalie> Sukhdev: I am ok.
16:38:16 <Sukhdev> later in the day also works for me
16:38:58 <Sukhdev> moving on ...
16:39:04 <Sukhdev> #topic: Trunk port binding for VLAN-awere VMs
16:39:22 <Sukhdev> #link: https://review.openstack.org/#/c/243786/
16:39:36 <Sukhdev> I raised the port binding issue on the spec
16:40:15 <Sukhdev> there is a good discussion going on the spec - feel free to jump in and provide feedback
16:41:17 <Sukhdev> there are couple of proposals - if it matters to you, you may want to voice your opinon on the spec
16:41:45 <Sukhdev> Anybody has anything else/more on this?
16:42:45 <Sukhdev> moving right along -
16:43:14 <Sukhdev> #topic: modular l2 agent discussion
16:44:07 <Sukhdev> is scheuran here?
16:44:40 <sc68cal> I think he's euro t
16:44:42 <sc68cal> *tz
16:44:47 <scheuran> Sukhdev, posted a quick update in the community
16:45:01 <scheuran> attending another meeting right now...
16:45:12 <scheuran> community = wiki
16:45:14 <Sukhdev> busy man :-)
16:45:18 <scheuran> :)
16:45:26 <Sukhdev> yes - I saw the update
16:46:06 <Sukhdev> I like the approach
16:46:33 <Sukhdev> I knew you were in the middle of update/rebase etc..so, put the review on hold
16:47:07 <rkukura> can someone post a link to that wiki?
16:47:26 <scheuran> sorry, meant the ml2 meeting wiki
16:47:43 <Sukhdev> rkukura: it is on the agenda of this meeting
16:48:32 <Sukhdev> Anything else on this?
16:48:48 <Sukhdev> scheuran : thanks for the update
16:49:16 <Sukhdev> shiv is not here, so, I am going to skip the physical topology topic
16:49:37 <Sukhdev> #topic: limited-portsec Discussion
16:49:37 <rkukura> OK, was looking for a link to a different wiki. I’ve been reviewing scheuran’s patches
16:49:51 <Sukhdev> yalie: you are up
16:50:07 <scheuran> rkukura, thanks for review!
16:50:17 <Sukhdev> rkukura: sorry for coufusion
16:50:38 <Sukhdev> yalie : this is your topic - care to elaborate?
16:51:37 <Sukhdev> looks like yalie : stepped away - we will come back to it -
16:51:55 <Sukhdev> need to move on to the next topic - we have only 9 min
16:52:18 <Sukhdev> #topic: Open Discussion
16:52:39 <Sukhdev> I added an item there to suggest an upstream change
16:53:07 <yalie> yes
16:53:08 <yalie> Sukhdev: limited-portsec
16:53:08 <yalie> ?
16:53:08 <Sukhdev> to pass network_id to the type drivers so that vendor specific type drivers can utilize it
16:53:08 <yalie> it's for a unaddressport
16:53:08 <yalie> after talk with Kevin, we found it's better to implent compatibal with port-sec
16:53:09 <yalie> yes,
16:53:10 <yalie> we could move on the next
16:53:38 <Sukhdev> yalie : Ok
16:53:51 <Sukhdev> rkukura : I need your thought/feedback on it
16:54:11 <Sukhdev> rkukura : I listed three methods that will be impacted -
16:54:27 <rkukura> Sukhdev: I don’t see any issue with passing the network_id to the type drivers. I’d need to look and see if the TX creating the network has already been committed when these calls are made.
16:55:00 <Sukhdev> rkukura : good point
16:55:40 <Sukhdev> How do I check that?
16:55:52 <rkukura> It could be useful either way. The TD might want to associate additional data with the network. BTW, don’t we now have segment_ids too??
16:56:36 <Sukhdev> this is when the segment_id is assigned by the type driver
16:56:50 <Sukhdev> so, yes
16:57:24 <Sukhdev> rkukura : let me push the patch later today - will ping you to look at it
16:57:59 <rkukura> ok
16:58:16 * Sukhdev 2 min left
16:58:29 <Sukhdev> anybody has anything for the last minute?
16:58:56 <yalie> could someone take a look a limited-portsec patch? :)
16:58:56 <Sukhdev> yalie : ?
16:59:04 <yalie> much appreicated!
16:59:08 <Sukhdev> yalie : I will
16:59:33 <yalie> Sukhdev: Thanks, I am not sure I am in a right direction, thanks
16:59:53 <Sukhdev> yalie : we'll figure it out :-)
17:00:08 <Sukhdev> others please review as well
17:00:12 <rkukura> yalie: Does the suggestion to just add to the existing portsec extension make sense?
17:00:54 <yalie> yes, before it was,
17:01:03 <Sukhdev> Folks, we are out of time
17:01:09 <Sukhdev> Thanks for attending
17:01:10 <rkukura> yalie: I’ll review that
17:01:12 <yalie> but make port-sec tri-value break the compatible
17:01:15 <yamamoto> bye
17:01:21 <rkukura> Sukhdev: Thanks for chairing! Enjoy your time off!
17:01:27 <Sukhdev> #endmeeting