16:03:07 <rkukura> #startmeeting networking_ml2
16:03:07 <openstack> Meeting started Wed Jun 11 16:03:07 2014 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:10 <openstack> The meeting name has been set to 'networking_ml2'
16:03:30 <shivharis> sukhdev: hi
16:03:42 <Sukhdev> shivharis: Hi
16:03:45 <rkukura> #agenda https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_June_11.2C_2014
16:03:59 <Sukhdev> shivharis: sorry was busy
16:04:04 <rkukura> #topic Announcements
16:04:27 <rkukura> Juno-1 should be cut today!
16:04:52 <rkukura> mestery is trying to allow the APIC L3 patch, which has been approved, to merge 1st
16:05:20 <rkukura> overall project plans are at https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
16:05:53 <rkukura> We need to identify the top priorities for ML2 and get these incorporarated into the plan
16:06:24 <Sukhdev> https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
16:06:28 <shivharis> rkukura: thx for the pointer
16:06:46 <rkukura> finally, mestery wanted me to emphasize that 3rd party CI needs to be working properly for ML2 drivers to stay in tree
16:06:56 <sadasu> https://review.openstack.org/#/c/95236/ review for ML2 UCS manager mech driver
16:07:06 <rkukura> he will be sending an email soon with details and deadlines
16:07:08 <sadasu> took care of all review comments last week
16:07:26 <rkukura> sadasu: Lets cover that in the code reviews topic
16:07:30 <sadasu> would really appreciate if the reviewers went and took a 2nd look
16:07:38 <sadasu> it is the BP review
16:08:08 <rkukura> mestery has details on 3td party testing requirements in https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
16:08:10 <banix> sadasu: we will get to it; hold on a few more minutes :)
16:08:14 <sadasu> rkukura: ok
16:08:42 <rkukura> any discussion on these announcements, or any other announcements?
16:08:43 <rcurran> rkukura, should we work w/ mestery to get BPs listed in https://wiki.openstack.org/wiki/NeutronJunoProjectPlan
16:09:04 <mestery> rcurran: No, those are community items of high importance. :)
16:09:13 <mestery> rcurran: The BPs you file will be in the milestone pages on Launchpad
16:09:13 <rkukura> rcurran: Yes - plan to discuss prioritization under that action items topic
16:09:19 <rcurran> and i'm not :-)
16:09:31 <rcurran> got it
16:09:57 <rkukura> anything else on announcements before we move on to action items?
16:10:19 <banix> good wiki on tests; specific requirement stated clearly
16:10:28 <banix> I meant the CI requirement
16:10:31 <yamamoto> what’s APIC L3?
16:10:40 <rcurran> cisco apic
16:10:51 <asomya> yamamoto: This patch https://review.openstack.org/#/c/96187/
16:11:06 <yamamoto> thank you
16:11:08 <rkukura> yamamoto: Its an L3 service plugin that goes along with Cisco’s APIC ML2 MD
16:11:29 <rkukura> asomya, rcurran: Is that accurate?
16:11:32 <rcurran> yes
16:11:45 <rkukura> #topic Action Items
16:12:08 <rkukura> 1st AI: rkukura to put priorities in specs etherpad
16:12:33 <rkukura> 2nd AI: rkukura to talk to mestery for blueprint priorities
16:12:34 <shivharis> close this based on delegating to individuals?
16:12:45 <shivharis> ^^^ 1st
16:12:58 <shivharis> or leave it around?
16:13:00 <rkukura> shivharis: let me update on the discussion with mestery 1st
16:13:05 <shivharis> k
16:13:13 <shivharis> rkukura: ok
16:13:38 <rkukura> So mestery suggests vendor-specific drivers should be at low priority, consistent with vendor plugins and vendor service drivers
16:14:15 <rkukura> The ML2 team can identify 2 or 3 BPs to treat as high priority
16:14:39 <rkukura> These need to be of general community interest, and really important to complete for Juno
16:15:15 <rkukura> And we can identify several more BPs to treat as medium priority, which also should be of general community interest
16:15:34 <rkukura> mestery: Does that summarize our conversation reasonably well?
16:15:51 <banix> sounds reasonable
16:16:30 <yamamoto> vendor-specifc drivers include ovs ones or not?
16:16:42 <rcurran> rkukura, should the authors of the vendor-specific BPs be concerned that there change may not get in
16:16:49 <mestery> rcurran: Yes, good summary!
16:17:23 <rkukura> yamamoto: I think OVS and linuxbridge are not considered vendor specific, so could be medium or high
16:17:28 <rcurran> mestery, good summary of what? :-) that my changes may not get in juno
16:17:39 <mestery> rcurran: ;)
16:17:50 <mestery> rcurran: Sorry, meant rkukura :)
16:17:58 * mestery blames the silly Limechat autocomplete.
16:18:01 <yamamoto> rkukura: sounds reasonable.  thanks for clarification
16:18:15 <rcurran> mestery, i'm actually glad it wasn't my "summary"
16:18:33 <rkukura> We clearly need to ensure vendor specific drivers are able to get merged
16:18:42 <banix> well, rcurran your summary may have been stated accurately as well
16:19:11 <rkukura> I think the process of having good subteam internal reviews, then handing over to core review, will help
16:19:27 <rkukura> Just because something is low priority doesn’t mean it should not get in
16:20:08 <trinaths> rkukura: +1
16:20:16 <shivharis> low priroity has an impact in when it gets reviewed
16:20:24 <rkukura> I expect cores outside our subteam are willing to +2 and +A vendor drivers if the subteam has done a thorough job of reviewing the code, and its clrearly ready to merge
16:21:00 <Sukhdev> rkukura: makes sense
16:21:03 <trinaths> subteam reviews really help..
16:21:10 <rkukura> How about if we provide a list of reviews that we think are ready for core review at each weekly neutron meeting?
16:21:27 <banix> rkukura: that should be helpful
16:21:33 <shivharis> bugs and bps?
16:21:41 <sadasu> rkukura: +1
16:21:47 <rkukura> shivharis: yes
16:21:48 <trinaths> rkukura: +1\
16:22:29 <Sukhdev> rkukura: that is a great idea
16:22:33 <nlahouti_> rkukura:+1
16:22:37 <shivharis> can we add a flag in the bps that it is ready, i can sort for the next meeting, need similar things for bugs
16:22:50 <rkukura> so I think our objective at these weekly ML2 meetings should be to decide which spec and code reviews to put forward at the next neutron meeting
16:23:05 <shivharis> rkukura: +1
16:23:14 <banix> rkukura: +1
16:23:25 <trinaths> rkukura: +1.
16:23:30 <rkukura> as well as to work through issues identified in the reviews that need discussion
16:23:46 <slogan_> I'm interested in doing code reviews, particularly of drivers since I am in learning mode, but not sure what the subteam concept is or how it applies. Can someone briefly suggest how I can help?
16:24:03 <yamamoto> in that case how about moving meeting date so that ml2 meeting is before neutron meeting in a week?
16:24:23 <Sukhdev> slogan_: just review the code that you are interested in post the comments
16:24:41 <rkukura> slogan_: The idea is to have the subteam (all of us at this meeting) find all the issues before asking cores to review the specs and code
16:25:12 <rkukura> so the core reviews can quickly and easily +2 and +A the patches
16:25:22 <chuckC> slogan_: is the problem finding reviews for the subteam?
16:26:00 <trinaths> subteam reviews make team, to learn more.
16:26:46 <slogan_> perhaps, I've just been randomly looking for neutron reviews so far in the list on gerrit that don't have a green checkbox.
16:26:47 <rkukura> We started using an etherpad to try to track progress on the BP spec reviews, with each reviewer entering info into the etherpad as they do reviews. This should allow reviewers to see which specs need review, which are close to handing over for core review, etc.
16:26:56 <slogan_> ah
16:27:09 <slogan_> where can i find that etherpad?
16:27:34 <banix> rkukura: for my own sake i made a wiki and organized the specs to review; not sure if useful to others but i put a link on etherpad
16:27:34 <shivharis> slogan_: we need to create one
16:27:38 <rkukura> slogan_: Its in the meeting agenda under Spec Reviews
16:27:45 <trinaths> slogan_: https://etherpad.openstack.org/p/Neutron_ML2_Juno_Spec_Tracking
16:28:10 <slogan_> looking :-)
16:28:37 <rkukura> banix: Any chance we could merge the wiki and etherpad into one definitive source that the team can use?
16:29:05 <shivharis> need one for bugs? or is it an overkill?
16:29:07 <yamamoto> banix: we should have a single place to look
16:29:12 <banix> rkukura: Sure, which one would be the best?
16:29:28 <banix> yamamoto: agree; if wiki not good, lets remove the link from etherpad
16:29:39 <rkukura> shivharis: Maybe for bugs with priorities over some threshold
16:29:56 <Sukhdev> rkukura: I like banix wiki - but, am concerned about keeping the etherpad and wiki in sync all the times
16:29:59 <shivharis> rkukura: agree
16:30:22 <sadasu> question about the etherpad
16:30:31 <banix> Sukhdev: yeah we have to pick one and go with it
16:30:37 <rkukura> sadasu: go ahead
16:30:37 <yamamoto> i’m fine with either or wiki or etherpad as far as it’s a single place
16:30:53 <nlahouti> banix: the wiki has good info.
16:30:54 <sadasu> do the spec/code owners update the etherpad when they have posted a new version?
16:30:55 <rkukura> so is etherpad or wiki the better tool for this?
16:30:57 <Sukhdev> banix: If I have to pick, I will pick the wiki - it is much better to read - :-)
16:31:02 <rkukura> We can move the info to one place
16:31:13 <sadasu> or is that unnecessary because of the email going out
16:31:15 <trinaths> banix: wiki page looks good.
16:31:45 <rkukura> banix: Where is the wiki?
16:31:56 <yamamoto> https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
16:32:01 <trinaths> rkukura: https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
16:32:01 <banix> #link https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
16:32:30 <trinaths> rkukura: we can send this page to core reviewers for easy access and reviews.
16:32:38 <rkukura> nice
16:33:09 <rkukura> table is certainly nicer than outlines on etherpad
16:33:44 <banix> the wiki has the info from etherpad from a couple of nights ago; whichever format we decide to use, I make sure both docs are in sync and then remove the less desirable one.
16:33:44 <shivharis> banix: like it
16:33:58 <rkukura> could we capture in each reviewer’s box a summary of their view of the status?
16:34:22 <banix> rkukura: like +1 or -1? or more info?
16:34:57 <rkukura> how about +1, +2, or tiny summary of issue resulting in -1 or -2
16:35:03 <trinaths> capturing a -1 would be helpful.
16:35:22 <trinaths> this helps for owners to be on improvements.
16:35:44 <banix> rkukura: timfreund the vote is certainly doable, a summary may become too much but will try and see how it comes out
16:35:45 <chuckC> each reviewer updates the table?
16:35:59 <Sukhdev> So, looks like we are settling with the Wiki..right?
16:36:06 <rkukura> chuckC: I think that is the goal, or it will become obsolete very quickly
16:36:07 <banix> trinaths: ^^^ sorry mistyped your id
16:36:23 <rkukura> anyone opposed to dropping the etherpad and using the wiki?
16:36:38 <banix> chuckC: yeah using the table i went through a few and added my name there
16:36:43 <slogan_> As long as we aren't duplicating what is already in the review - anyway to mine it from gerrit automatically?
16:36:55 <shivharis> wiki looks organized
16:37:04 <chuckC> so, summary or no summary?
16:37:25 <trinaths> chuckC: summary might make the page crowed.
16:37:38 <rkukura> #agreed We will track BPs using https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews instead of the etherpad
16:37:40 <Sukhdev> trinaths: +1
16:37:51 <yamamoto> trinaths +1
16:37:53 <banix> slogan_: i started looking at options like that but i think there are not that easily doable with the wiki support in OpenStack
16:37:58 <banix> rkukura: please give me an action item to consolidate
16:38:24 <rkukura> #action banix to consolidate info from spec tracking etherpad into https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
16:38:54 <slogan_> like the wiki too, thanks. It gives me a place to find reviews to work on that are directly related to the work I plan to do in openstack once (if) I am able to contribute
16:38:57 <shivharis> add to the etherpad that it is deprecated to no one adds more to it
16:39:05 <trinaths> banix: you may have a review column, with numer of reviews (+1's) so that the subteam review weightage can be considered.
16:39:05 <banix> I will spend a bit more time wrt having summary and other info and see how it goes.
16:39:16 <Sukhdev> banix: BTW, Big Thank you for putting together this wiki
16:39:34 <banix> shivharis: yes, after consolidation will remove content from ethrpad and have a pointer there only
16:39:39 <rkukura> Back to my 2 AIs, (how) do we incorporate BP prioritization into the wiki?
16:40:02 <banix> Sukhdev: no problem at all (all the colors on the etherpad were bugging me :) )
16:40:17 <trinaths> rkukura: we add a priority column
16:40:18 <Sukhdev> banix: :)
16:40:24 <rkukura> From this point forward, reviewers should update the wiki rather than the etherpad, right?
16:40:32 <trinaths> yes
16:40:37 <Sukhdev> rkukura: correct
16:40:52 <banix> Will remove the etherpad by the end of day today
16:40:56 <slogan_> do we need some notes on the wiki about how and when to update?
16:41:04 <yamamoto> rkukura: separate tables for each priorities?
16:41:04 <trinaths> banix: also, can we have code review link too in the table. any comments?
16:41:10 <Sukhdev> rkukura: we should add the wiki link into the meeting agenda
16:41:15 <rkukura> OK, lets add priority as column and keep items in each table sorted by decreasing priotity
16:41:18 <banix> slogan_: sounds like a good idea
16:41:25 <rkukura> Sukhdev: right
16:41:40 <banix> trinaths: you mean for things other than the specs?
16:41:44 <chuckC> yamamoto: +1
16:41:56 <slogan_> for example, do I just put my name in the first Rn column that is empty if I give any review comments, or if I give a +1?
16:41:58 <trinaths> rkukura: or we can reorganize with priorities, rather than a column.
16:42:26 <rkukura> Do we want separate tables on the wiki for spec reviews vs. code reviews?
16:42:49 <trinaths> banix: yes, this page shows specs, can we have another page for code or have a column in this table with code review too if there is a code commit.
16:42:55 <Sukhdev> trinaths: I thought about it as well, but, I think it will be harder to manage
16:43:06 <Sukhdev> rkukura: 16 min left
16:43:16 <banix> running out of time :) will update and send email to the ML and you can send me your comments as well
16:43:17 <rkukura> Too many columns would be a problem
16:43:33 <trinaths> banix: it makes us aware, development is happening
16:43:37 <trinaths> okay..
16:43:47 <banix> trinaths: sure will work on it
16:43:47 <rkukura> OK, next AI
16:43:50 <rkukura> Sukhdev to investigate bug 1193861
16:43:51 <Sukhdev> rkukura: I had an AI
16:43:51 <uvirtbot> Launchpad bug 1193861 in neutron "ML2 plugin needs to override bulk operations" [Medium,Triaged] https://launchpad.net/bugs/1193861
16:43:57 <shivharis> all: i have someone visiting me, need to drop off. ttly on irc. will catch up with the summary
16:44:07 <rkukura> Any update Sukhdev?
16:44:10 <Sukhdev> Sukhdev: Yes, I went and spoke to Andre about this bug
16:44:14 <rkukura> shivharis: Thanks!
16:44:26 <banix> shivharis: bye
16:44:32 <Sukhdev> according to https://wiki.openstack.org/wiki/Neutron/APIv2-specification
16:44:42 <trinaths> banix: will mail you a layout on this.
16:44:50 <banix> trinaths: great; thx
16:44:51 <Sukhdev> Neutron API support bulk create operations- this bug is about that
16:45:38 <Sukhdev> What this bug states is that if a bulk create operation comes down to ML2 Plugin - how do we deal with it, if one of the operations fail
16:46:00 <Sukhdev> rkukura: I did not know we support bulk operations in ML2 Plugin, do we?
16:46:25 <Sukhdev> rkukura: if we do, then this bug is valid - if we do not, then we should close this bug
16:46:43 <rkukura> Sukhdev: I thought they were implemented in the REST layer by calling individual plugin methods for each, not sure if its all inside one big TX or not.
16:46:58 <banix> Sukhdev: yes they are supported implicitly
16:47:14 <banix> Sukhdev: but now you should be able to disallow it
16:47:20 <rkukura> If its inside one TX, then its a bug because postcommits should not be called in transactions
16:47:34 <Sukhdev> rkukura: according to document, it seems to imply that bulk operation is passed down to plugin and it manages as a TX
16:48:25 <rkukura> We need to decide if this bug is a priotity for Juno, and if so, have someone investigate and propose solution
16:48:27 <Sukhdev> rkukura: So, how will rest layer handle, if we failed one of the create operations?
16:48:42 <rkukura> Sukhdev: Don’t know - needs investigation
16:48:57 <chuckC> I suspect TripleO may have a need for bulk (scalable) operations….
16:49:01 <Sukhdev> rkukura: good question Juno or later?
16:49:04 <rkukura> Anyone want to take this, or is Andre taking it?
16:49:33 <Sukhdev> rkukura: Andre is not going to take it for Juno
16:49:57 <rkukura> last AI was me talking with markmcclain re taskflow, but no progress on that yet except for a quick chat with mestery
16:50:17 <Sukhdev> Does it help or impact anyone here in this team? if yes, we can escalate - otherwise postpone it
16:50:22 <rkukura> Would anyone else like to investigate this bulk ops bug?
16:50:38 <markmcclain> rkukura: salv-orlando has also been working on task items too
16:50:39 <banix> rkukura: will do
16:51:12 <Sukhdev> markmcclain: can you share any link/document on the subject?
16:51:14 <rkukura> markmcclain: Want to see if we can/should use task flow internally in ML2 and/or in specific ML2 drivers
16:51:39 <banix> markmcclain: or possibly L2 agents
16:51:43 <rkukura> #action: banix to investigate https://launchpad.net/bugs/1193861
16:51:44 <uvirtbot> Launchpad bug 1193861 in neutron "ML2 plugin needs to override bulk operations" [Medium,Triaged]
16:51:57 <markmcclain> rkukura: ideally yes
16:52:13 <Sukhdev> rkukura, markmcclain: I did some brain storming with folks at Arista and we felt that we may still need sync mechanism regardless
16:52:36 <rkukura> markmcclain: This is kind of separate from the discussion about exposing tasks in the API. Can we discuss offline this week?
16:52:49 <markmcclain> yeah I don't think we'll fully be able to get rid of sync'ing but we should be able to reduce the amount of it
16:53:01 <rkukura> only 8 minutes left
16:53:08 <rkukura> #topic Bugs
16:53:08 <markmcclain> rkukura: yes.. I'm PDT this week
16:53:14 <rkukura> markmcclain: ok
16:53:34 <rkukura> Any bugs that need discussion right now?
16:54:02 <rkukura> #topic Spec Reviews
16:54:20 <rkukura> We already covered the process enough for today
16:54:37 <rkukura> One spec review that needs some discussion is https://launchpad.net/bugs/1193861
16:54:38 <Sukhdev> rkukura: skip it
16:54:40 <uvirtbot> Launchpad bug 1193861 in neutron "ML2 plugin needs to override bulk operations" [Medium,Triaged]
16:54:48 <rkukura> wrong past
16:54:50 <rkukura> paste
16:55:01 <nlahouti> https://blueprints.launchpad.net/neutron/+spec/vdp-network-overlay not approved yet. any update on reviewing it?
16:55:04 <rkukura> https://review.openstack.org/#/c/89208/
16:55:29 <banix> sadasu: you may also want to mention yours here again
16:55:29 <sadasu> https://review.openstack.org/#/c/95236/ review for ML2 UCS manager mech driver
16:55:35 <rkukura> nlahouti: In general, we are not making good progress on the reviewing the specs. I am way behind on this myself.
16:55:52 <sadasu> posted updated version based on all comments received so far
16:56:27 <nlahouti> rkukura: that spec doesn't have -1 and lots of review and discussion done
16:56:31 <sadasu> last week..could you pls take a look again?
16:56:47 <rkukura> The review I pasted has to do with extensions, and we may want to consider adding a new type of driver, ExtensionDriver, to ML2. Lets discuss this next week if not resolved.
16:56:57 <nlahouti> rkukura: yes
16:57:17 <Sukhdev> rkukura: my last week was very busy - I intend to go back and give another review to all the specs this week
16:57:33 <sadasu> Sukhdev: thanks!
16:57:48 <asomya> https://review.openstack.org/#/c/91811/ has two +1's .. ready for core review?
16:57:54 <nlahouti> rkukura: that is for extension - can we consider implementing the proposal and add improvement later
16:58:06 <Sukhdev> asomya: yes, I have been watching it :-)
16:58:20 <rkukura> nlahouti: I’m not comfortable about the currently proposed driver API changes
16:58:40 <rkukura> nlahouti: Lets continue the discussion in the review and etherpad
16:58:44 <asadough1> rkukura: i haven't heard any new ideas on ovs-firewall-driver recently and am strongly considering postponing it to K-cycle given current lack of positive momentum
16:59:04 <nlahouti> rkukura: ok will do.
16:59:25 <Sukhdev> rkukura: 1 min left
16:59:27 <rkukura> asadough1: Is there a specific proposal on how to reject firewall rules that cannot be enforced?
16:59:45 <rkukura> #topic Open Discussion
16:59:52 <banix> Have a look at Modular L2 agent when you get a chance and let me know what you think: #link https://review.openstack.org/#/c/99187/ link toetherpad in the commit message
17:00:03 <rkukura> banix: Should we put Modular Agent near top of agenda for next week?
17:00:04 <asadough1> rkukura: the suggestion for API validation was added to the blueprint
17:00:09 <yamamoto> how about rotating the order of topics to discuss for each meetings so that every topics will be discussed eventually? :-)
17:00:21 <banix> rkukura: sure
17:00:43 <rkukura> times up, anything else?
17:00:58 <rkukura> #endmeeting