16:00:45 <Sukhdev> #startmeeting networking_ml2
16:00:46 <openstack> Meeting started Wed Sep  3 16:00:45 2014 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:50 <openstack> The meeting name has been set to 'networking_ml2'
16:00:59 <shivharis> hi
16:01:16 <Sukhdev> #topic: Agenda
16:01:27 <Sukhdev> https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_September_3.2C_2014
16:01:56 <Sukhdev> topic: Announcements -
16:02:19 <Sukhdev> The FF for Juno is over as of this morning
16:02:44 <Sukhdev> Anything which is not already merged will be removed from Juno and moved into Kilo
16:02:49 <shivharis> one thing to keep in mind the feature freeze happens a day before the announced date - due to queuing of patches etc.
16:03:05 <Sukhdev> shivharis: correct
16:03:05 <rkukura> clarification  - this is anything not already approved
16:03:32 <rkukura> things approved and in the merge queue (which is 18 hours behind) may make Juno
16:03:51 <emagana> sorry, I am late!
16:03:52 <Sukhdev> rkukura: thanks for clarification - want to add more?
16:04:15 <rkukura> There is an FFE process to get additional features in
16:04:18 <Sukhdev> emagana: you will buy cookies for everybody :-)
16:04:37 <emagana> Sukhdev: cookies?  what about beer?
16:04:39 <rkukura> But my understanding is that FFEs are only for medium and high priority BPs
16:05:00 <rkukura> Which unfortunately excludes all vendor drivers
16:05:35 <emagana> rkukura: I believe just for High priority BPs
16:05:44 <emagana> rkukura: an essetial of course!
16:05:56 <rkukura> emagana: Not sure about that, but you may be right
16:05:57 <Sukhdev> rkukura: how about couple of our BPs? Shall we make a case or not?
16:06:33 <rkukura> Sukhdev: I think this is something we should discuss here now
16:06:57 <Sukhdev> rkukura: correct - that's why I brought it up
16:07:19 <rkukura> The hierarchical port binding BP was high, but I think is now medium
16:07:46 <Sukhdev> rkukura: depends upon how many vendors need it -
16:08:05 <rkukura> The 3rd part of the type driver refactor and the external ports are the other medium BPs
16:08:06 <Sukhdev> This is the time to speak up - if you believe you (or your company) plans to use it
16:08:30 <asadoughi> hi
16:09:28 <asomya> Sukhdev: we at Cisco plan to use it
16:09:32 <rkukura> The Cisco DFA driver was planning to use hierarchical port binding in Juno, but its VDP patch was deferred to Juno, and then the rest of it
16:09:32 <rcurran> rkukura, Sukhdev +1 for cisco_nexus md requiring
16:09:59 <banix_> asadoughi: look what you did! :)
16:10:14 <rkukura> I think Cisco’s hope was that the drivers not using in Juno would do so early in Kilo, and then backport to stable-juno
16:10:38 <rcurran> rkukura, correct
16:10:39 <rkukura> rcurran: Is that accurate?
16:11:07 <Sukhdev> rkukura: Any body else?
16:11:21 <rkukura> So it is a real issue for Cisco at least if this doesn’t get an FFE, but its hard to justfiy the FFE for just one vendor when no merged code needs the feature.
16:11:58 <Sukhdev> rkukura: that is why I am trying to see if somebody else would jump in as well
16:12:08 <trinaths> Hi all
16:12:24 <rkukura> I think the net split might be one reason noone is responding
16:13:23 <Sukhdev> rkukura: I think we should make a strong case for it, and be willing to accept the defeat - if we could not get through
16:13:29 <rkukura> Are there any other mechanism drivers that would potentially make use of hierarchical port binding early in Kilo, and backport this to Juno if this BP gets an FFE and makes Juno?
16:14:14 <nlahouti> cisco DFA
16:14:23 <Sukhdev> I checked at Arista, we will use it in the late stage of Kilo (or bit later)
16:14:45 <shivharis> not for brocade
16:14:49 <rkukura> Is stabiizing the driver API in Juno rather than waiting for Kilo an argument for an FFE (of course there will be other changes in Kilo, …)?
16:15:49 <rcurran> rkukura, i take it at this point you don't need to see my continual +1's
16:16:13 <rkukura> rcurran: I’m not rulling out applying for an FFE.
16:16:20 <trinaths> For FSL, we will use at later stage.
16:16:22 <asomya> rkukura: +1, also if we push this into Juno, vendors can start writing drivers based on it as soon as Kilo opens.. otherwise wait for this to go into Kilo and risk not getting their drivers upstream
16:16:38 <rkukura> mestery has not entirely ruled it out either, AFAIK
16:16:48 <Sukhdev> rkukura: it seems reasonable argument - we have a vendor who needs it now and also we get to bake the API
16:17:18 <trinaths> +1 rkukura.
16:17:27 <rkukura> Is there anyone here who would object to an FFE for the heirarchical port binding BP patches to merge in Juno?
16:17:34 <Sukhdev> asomya: agree
16:18:24 <Sukhdev> Are Akihiro and Amando here?
16:18:41 <amotoki> Sukhdev: hi
16:19:07 <Sukhdev> amotoki: I saw your -1 on the patch, and thought, perhaps you would want to jump into this discussion
16:19:46 <amotoki> Sukhdev: thanks for letting me know. I don't have a strong opinion on it. Bob's reply also sounds reasonable to me.
16:20:24 <rkukura> amotoki: Would you have any objection to an FFE being granted if we decide to request one?
16:20:46 <amotoki> rkukura: no
16:21:16 <rkukura> OK, sounds like its worth a shot, although with its priority now at medium, it may not fly.
16:21:21 <amotoki> rkukura: i just would like to clarify what value we can have if it is merged in Juno.
16:21:39 <Sukhdev> What is Amando's IRC?
16:21:50 <padkrish> atleast DFA will start using it early in kilo...well, ofcourse after the BP gets re-approved and so on...
16:21:51 <amotoki> rkukura: i think it is a good shape and row risk to me.
16:21:57 <Sukhdev> He also had -1 with strong comments
16:22:28 <emagana> Sukhdev: it is armax
16:22:31 <rkukura> amotoki: That what we’ve been discussing - mostly at this point just enabling the drivers to make use of this in early Kilo, and potentially backport to Juno
16:22:46 <Sukhdev> armax: are you here?
16:22:53 <Sukhdev> emagana: Thx
16:22:57 <rkukura> I believe I’ve addressed armax’s concerns in gerrit
16:23:05 <chuckC> armax is not online right now
16:23:06 <amotoki> rkukura: exactly. I am now reading the log.
16:23:27 <rkukura> Of course, if an FFE is granted, it still wouldn’t merge until his concerns are resolved.
16:23:43 <emagana> If the value for the heirarchical port binding BP is just having a vendor specific driver advantage, then I am not in favor!!
16:23:47 <Sukhdev> rkukura: cool - looks like we seem to have converged
16:23:51 <rkukura> Are there other ML2 BPs we should discuss FFEs for?
16:24:17 <rkukura> emagana: Its not an advantage for any one vendor - its useful to all
16:24:46 <Sukhdev> #action: rkukura to work on getting FFE for two port binding BPs
16:24:52 <emagana> rkukura: Let me explain it better, which driver will use it in Juno?
16:24:59 <rkukura> Sukhdev: One one BP, but three patches
16:25:00 <emagana> rkukura: if it gets merged?
16:25:35 <Sukhdev> rkukura: opps..
16:25:35 <amotoki> I know cases where vxlan offload on server side does not work effectively and switch side network overlay is needed for performance.
16:26:00 <rkukura> emagana: The design was done during the Juno summit, with multiple vendors participating. Merging it allows them all to proceed with taking advantage of it in their drivers, at whatever pace they choose
16:26:41 <amotoki> my comment comes from not as a plugin maintainer but as one of operators using OpenStack.
16:27:10 <rkukura> amotoki: That’s useful to know!
16:27:28 <Sukhdev> amotoki: I have heard it form many people as well (including customers)
16:27:31 <emagana> rkukura: Got it! Well, I understand it better.. I think is worth to give it a shot for FFE
16:27:54 <rkukura> The advantage of the hierarchical binding is that it lets vendor-specific ToR drivers coexist and work toghether with open source host-level drivers like openvswitch, hyperv, ...
16:27:57 <Sukhdev> #action-undo
16:28:01 <rkukura> emagana: thanks
16:28:17 <amotoki> what we need to consider is the timing such change in the framework is proposed.
16:28:26 <Sukhdev> #action: rkukura to work on getting FFE for port binding BP
16:28:36 <rkukura> amotoki: Lets have that discussion around the FFE
16:29:06 <Sukhdev> Anything else on this topic?
16:29:15 <rkukura> Other BPs?
16:29:27 <rkukura> what about external attachement points?
16:29:39 <rkukura> kevinbenton: has reworked this to make it much simpler
16:30:32 <Sukhdev> rkukura: It was not approved as of last night - did not check this morning
16:30:58 <rkukura> Wanted to see if kevinbenton was considering an FFE for this?
16:31:40 <Sukhdev> rkukura: Mark gave -2 on both of his patches
16:31:50 <rkukura> I’m not hearing any other FFEs being proposed, so time to move on Sukhdev
16:32:11 <amotoki> I see one point to be discussed on external attachment points. It allow to change tenant_id to allow users to use the external attachment point.
16:32:12 <Sukhdev> Any thing else folks?
16:32:25 <sadasu> How about the cisco ucs manager ml2 driver?
16:32:33 <sadasu> I would like to get an FFE for that
16:32:38 <Sukhdev> amotoki: I kind of like that BP and would have wished that it made it
16:33:01 <amotoki> Sukhdev: yes. I don't continue the discussion here.
16:33:04 <sadasu> are vendor specific drivers even considered for FFEs?
16:33:36 <rkukura> sadasu: My undestanding is that they are not, but you may want to get clarification from mestery
16:33:40 <Sukhdev> sadasu: it will be hard - what do you think rkukura?
16:33:41 <emagana> sadasu: Neutron PTL indicated that not!
16:34:11 <padkrish> Even i made a request for FFE for VDP BP....that's not really vendor specific...PTL has moved it to Kilo
16:34:21 <mestery> sadasu: Generally no, extenuating circumstances not included
16:34:23 <amotoki> I think FFEs are limited number of BPs up to about ~5(?)
16:34:33 <amotoki> we need to keep them controlled.
16:34:53 <Sukhdev> mestery: sadasu was so close - I thought it was ready to merge
16:35:03 <sadasu> I think I get the picture :-)
16:35:15 <rkukura> I also was ready to +2 the UCS driver as soon as it was updated
16:35:25 <emagana> sadasu: Is the a CI for Cisco UCS Manager?
16:35:53 <emagana> I mean: "Is there"
16:35:58 <sadasu> emagana: yes...I have it ready..just not integrated yet
16:36:05 <Sukhdev> mestery: rkukura's point is compelling in her favor :-)
16:36:45 <Sukhdev> Anyhow folks, we have discussed enough - time to move on
16:36:50 <amotoki> sadasu: emagana: we don't see any results on UCS from Cisco CI *now*
16:36:52 <emagana> sadasu: I will recommend working with dane on integrating all Cisco CIs if possible.. you have a few already  ;-)
16:37:02 <Sukhdev> #topic: Action Items from past week:
16:37:28 <sadasu> Sukhdev: thanks!
16:37:28 <Sukhdev> rkukura: want to provide update?
16:38:13 <rkukura> I have not yet submitted bugs on the DVR-related cleanup and issue, but will focus on that between FF and RC1
16:38:41 <rkukura> So lets keep that AI open, assuming these kinds of fixes are appropriate during this window
16:38:53 <Sukhdev> rkukura: sounds good - Will keep it open then
16:39:26 <Sukhdev> On the second item - I see nlahouti and rkukura got the victory
16:39:49 <Sukhdev> I see that patch has merged - congratulations nlahouti...
16:40:00 <nlahouti> Sukhdev: thx
16:40:08 <nlahouti> Sukhdev:  :)
16:40:19 <emagana> Sukhdev: +1
16:40:23 <Sukhdev> #topic: Code Reviews
16:40:36 <rkukura> I think there is some movement towards implementing more of the optional APIs in ML2 as extension drivers
16:40:48 <Sukhdev> We have pretty much cover this area
16:41:09 <Sukhdev> rkukura: can you clarify, please?
16:42:11 <rkukura> This was related to nlahouti’s patch, and various reviewers coming around to seeing its value (asside from vendor-specific extensions)
16:42:37 <Sukhdev> rkukura: got it....thanks
16:43:10 <Sukhdev> BTW, I updated the wiki https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews#Under_Review last night - many patches have merged - congratulations to those who made it...
16:43:34 <Sukhdev> Anything on Code reviews?
16:44:01 <Sukhdev> Going forward we will start to put emphasis on bugs and planning for Kilo Summit
16:44:22 <Sukhdev> #topic: Bugs:
16:44:45 <Sukhdev> shivharis: want to provide update?
16:45:06 <shivharis> one bug "high" for j3
16:45:10 <shivharis> https://bugs.launchpad.net/neutron/+bug/1359416 (status: high - j3, akihiro?)
16:45:12 <uvirtbot> Launchpad bug 1359416 in neutron "RPC callback should not use mixin approach" [High,In progress]
16:45:25 <amotoki> yes.core patches already landed.
16:46:08 <amotoki> two cleanup patches are remaining. one fixes only comments and the other fixes a degrade in mellanox plugin.
16:46:12 <Sukhdev> amotoki: I was hit by this, and saw the patch merge - took care of my issue
16:46:52 <irenab> amotoki: I'll take a look for mellanox plugin
16:47:14 <rkukura> Looks like mellanox fix is already approved and in the merge queue
16:47:16 <amotoki> irenab: https://review.openstack.org/#/c/118165/
16:47:26 <irenab> amotoki: thanks
16:48:01 <shivharis> amotoki: ?
16:48:01 <shivharis> this was the only one one my list that seemed important, i guess this will be juno
16:48:01 <shivharis> all others "bulk" etc will also be juno
16:48:01 <shivharis> moving forward we need to be more focused on bugs, not new code
16:48:52 <shivharis> amotoki: can this wait for Juno or do we need to make exception?
16:49:04 <amotoki> shivharis: which one?
16:49:34 <banix_> should get the rpc patches by amotoki in this cycle
16:49:37 <rkukura> between FF and RC1 is a good time to fix bugs, IMHO
16:49:41 <shivharis> irenab, amotoki: we will move this to J
16:49:58 <rkukura> shivharis: This is J
16:50:00 <shivharis> https://review.openstack.org/#/c/118165/
16:50:07 <amotoki> shivharis: most changes have been merged and it will shipped with J-3.
16:50:16 <Sukhdev> banix_: I had left some comment on your patch regarding second bug in the list - are you going to get it in Juno?
16:50:17 <banix_> shivharis: j
16:50:21 <amotoki> 118165 will be a part of j-3.
16:50:23 <shivharis> rkukura: +1
16:50:39 <banix_> Sukhdev: thanks; have been away for several days; back from today
16:50:56 <shivharis> amotoki: ok
16:51:19 <Sukhdev> banix_: This good work and am wondering if it will land in Juno?
16:51:21 <banix_> Sukhdev: your concern about testing, i have done unit tests only; what kind of tests do you want? specific to vendor plugins?
16:51:34 <shivharis> Any other questions on bugs?
16:51:52 <banix_> #link https://review.openstack.org/#/c/113999/
16:52:14 <Sukhdev> banix_: my concern is that if this is merged and implemented only partially, would it have any ill effects on the drivers
16:52:30 <Sukhdev> banix_: worried about last minute chaos in the release
16:52:43 <banix_> Sukhdev: i see; by partially you mean only bulk network, right?
16:52:53 <Sukhdev> banix_:correct
16:53:21 <banix_> i can update the patch shortly to cover subnet and ports as well; have the code was wondering if it would be easier to review a piece of it first
16:53:23 <Sukhdev> banix_: rkukura had the same concerns
16:53:45 <Sukhdev> banix_: we discussed it here last week - you were not present
16:54:11 <banix_> sure; thought this way the review will be easier; will update the patch with bulk ops for subnet and ports; the same framework; will address other comments as well
16:54:21 <rkukura> banix_: +1
16:54:30 <shivharis> banix_: will this be "requiring" changes in MDs
16:54:41 <banix_> shivharis: no
16:54:43 <Sukhdev> banix_: Thanks
16:55:06 <banix_> the only change beyond the main plugin is in a couple of places in unit tests for a cisco driver; that’s all.
16:55:09 <shivharis> banix_: thx
16:55:17 <Sukhdev> Anything else on the bugs?
16:55:26 <amotoki> what do you think about https://bugs.launchpad.net/neutron/+bug/1179223 ?
16:55:28 <uvirtbot> Launchpad bug 1179223 in neutron "Retired GRE and VXLAN tunnels persists in neutron db" [Medium,Confirmed]
16:55:41 <shivharis> that's all from me...
16:55:58 <romilg> I am working on it
16:56:02 <amotoki> what I am thinking is to delete related endpoint when agent-delete is called.
16:56:48 <Sukhdev> #topic: Open Discussion
16:56:53 <romilg> wht abt when we change the local_ip of any agent ?
16:56:56 <Sukhdev> we have 4 minutes
16:57:07 <Sukhdev> anybody want to bring up anything here?
16:57:18 <amotoki> romilg: let's discuss the arppoach in launchpad bug.
16:57:19 <padkrish> sukhdev# for those that didn't make it to Juno, in spite of lots of reviews....do they have to start from square1?  I mean, from Getting the BP re-approved ?
16:57:28 <romilg> Ok :)
16:57:41 <amotoki> it is a headache to me too.
16:58:11 <Sukhdev> padkrish: Good question - I do not believe you have to go through the BP approval process
16:58:17 <amotoki> padkrish: we don't have a concrete process for Kilo.
16:58:18 <shivharis> yes the bp needs re-approval
16:58:22 <Sukhdev> Anybody has better answer?
16:58:27 <banix_> padkrish: bp needs to be re approved but perhaps will go through quickly
16:58:39 <trinaths> BP needs approval
16:58:48 <banix_> padkrish: since it was already approved once
16:58:54 <trinaths> the process starts again.
16:58:59 <shivharis> PTL mentioned re-approval for bps
16:59:16 <padkrish> thanks everyone...another question regarding the functional tests...
16:59:27 <trinaths> shivharis: that means we need to re post the BP ?
16:59:41 <shivharis> yup
16:59:45 <Sukhdev> I think mestery is already tagging them for Kilo
16:59:52 <banix_> trinaths: yes; some discussions on ml a week or so ago
16:59:59 <padkrish> If openstack interacts with any external modules like brctl, OVS etc. it needs functional test cases? Any links/pointers apart from neutron/test/functional?
17:00:08 <Sukhdev> so. may require some minor process
17:01:00 <trinaths> when will the k-1 process open, timeline?
17:01:10 <amotoki> it seems time is over.
17:01:29 <shivharis> your bp will get a -2 and thats where the process begins for re-approval
17:01:30 <shivharis> kilo bps are in a diffeent directory
17:01:32 <Sukhdev> padkrish: how about tempest/tempest/scenario tests?
17:01:43 <yamamoto> time to move to #openstack-neutron i guess
17:01:54 <Sukhdev> amotoki: yes time is up - thanks for remider
17:02:02 <trinaths> okay bye all.
17:02:03 <Sukhdev> folks we are done - thanks
17:02:03 <banix_> bye
17:02:03 <rkukura> thanks Sukhdev !
17:02:05 <yamamoto> bye
17:02:05 <padkrish> sukhdev# Thnx...let's continue our discussion in other channels
17:02:07 <Sukhdev> #endmeeting