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