16:03:36 #startmeeting networking_ml2 16:03:36 Meeting started Wed Nov 19 16:03:36 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:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:03:40 The meeting name has been set to 'networking_ml2' 16:03:56 #link https://wiki.openstack.org/wiki/Meetings/ML2#Agenda 16:04:18 #topic Announcements 16:04:43 There will be a mid-cycle meetup in December in Utah 16:05:04 Info is at https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint 16:05:43 rkukura: Looks like there will be ML2 related work in this sprint 16:06:03 This is likely to be relevant to ML2 both in terms of vendor driver relocation and the core changes. 16:06:30 I encourage ML2ers to participate if possible 16:06:40 Any other announcements? 16:07:03 If not… 16:07:10 any possibility of remote attendance to the mid-cycle summit? 16:07:11 #topic Bugs 16:07:24 shivharis: 16:07:26 hi 16:07:27 HI 16:07:49 rkukura: any info on my previous question? 16:08:21 I have not combed the latest list this time, my apologies. I will open it up for folk who are actively working on bugs and if they need help 16:08:46 shivharis is probably jet-lagged like me :-):-) 16:09:18 there is a bug entered in the agenda, https://review.openstack.org/#/c/113999/ 16:09:33 yup, keeping odd hours due to jet lag 16:10:12 Doesn’t look like banix is online 16:10:15 appears very calm this time, lets get to these next time, i will be more prepared. 16:10:31 back to you bob. 16:10:34 Ok, any other bugs need discussion? 16:10:41 If not… 16:10:54 #topic Spec Reviews 16:11:37 https://review.openstack.org/#/c/99873/ 16:11:58 hi. 16:12:00 This is the portsecurity extension spec 16:12:13 rkukura: I had something to discuss but I can wait 16:12:17 yamahata: what’s the status on this? 16:12:18 till open discussion. 16:12:18 I would like reviewers for my spec on ML2 driver for UCS Manager 16:12:24 manishg: OK 16:12:31 Yes, there are three similar proposals. Now we are talking for combined spec. 16:12:36 #link https://review.openstack.org/134056 16:13:18 If the basic direction is okay for you and other core devs, I'd like to get -2 removed. 16:13:40 yamahata: Do you have links to the other proposals? 16:14:00 sadasu: I saw some comments on this - I will review it later today 16:14:27 https://review.openstack.org/#/c/106222/ 16:14:30 I see mestery’s -2 comment references one 16:14:32 Sukhdev: thanks! 16:14:33 https://review.openstack.org/#/c/97715/ 16:15:05 they are in reference section of the spec. 16:15:40 I’d suggest asking mestery to remove his -2 if there is agreement on which spec(s) go forward 16:15:41 yamahata: will yours be the combined spec? 16:16:03 yamamoto: Yes. At least I try to. 16:16:50 I’ll try to catch up on this review by next week 16:16:55 afaik, the other 2 spec owners are willing to collaborate with yamahata 16:17:03 shwetaap: do you have oany pinion? 16:17:26 s/oany/any 16:17:27 based on discussions during the summit 16:18:44 any other spec reviews to discuss? 16:18:58 I have not posted the updated HPB spec yet, but will very soon. 16:19:25 have a general question on spec reviews 16:19:30 We used to have a big list of specs - that got moved to Kilo - see this table https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews#Under_Review 16:19:32 sadasu: go ahead 16:19:54 Sukhdev: Thanks. 16:20:25 Lets continue to update the wiki as specs are submitted. 16:20:29 are spec approvals linked to what happens regarding reloaction of ML2 driver code? 16:20:29 This should be a straightforwrd spec: https://review.openstack.org/#/c/132226/ 16:20:31 Sorry but I am having a little bit of a connection problem here. What I had worked on for last cycle was to extend Aaron's port security extension in ML2. But the spec now is to have a port security as an extension driver in Ml2. I am in agreement with that. And yamahata , I would be interested in taking up any work in this regard 16:22:06 banix: Looks like we are continuing the spec process for vendor drivers, at least until the repository move is resolved. 16:22:27 rkukura: thanks for letting me know. I missed that point. 16:22:50 banix: welcome back!!! 16:22:59 Sukhdev: thanks 16:23:42 shwetaap, yamahata: Let us know if we need to put portsecurity on the agenda for next week 16:23:51 Anything else on specs? 16:24:18 sadasu: don't think spec approvals are linked to decision about ml2 driver code relocation (afaik) 16:25:19 manishg, sadasu, banix: My view is we should continue the spec process for vendor drivers for now. This might change if all vendor drivers move to vendor-specific repos. 16:25:29 We’ll discuss that in a bit. 16:25:34 manishg: good to know...we can make progress there 16:25:47 I do not have the spec yet, but we want to add QoS support for SRIOV ports, based on previously proposed patches by Sean Collins with some changes. It will require ML2 extension for QoS mapping to port and support for extendable get_device_details call into Extension Drivers. Can we discuss it here or need to push the spec first? 16:26:14 banix: are you just looking for a 2nd core reviewer for your spec? 16:26:22 irenab: is this really qos or just throttling? 16:26:25 sadasu: yes 16:26:36 irenab: Cool 16:26:42 manishg: rate limiting 16:27:00 irenab: rate limiting by nic hw? 16:27:10 yamahata: yes 16:27:20 irenab: then maybe better to just call it that. qos brings in other implications and people will claim spec incomplete for qos. 16:27:30 irenab: Not sure why the get_device_details would call into the extension drivers - these just manage the DB state - the mechanism drivers would need to enforce the extension semantics 16:28:01 Which brings up the question of whether we want to work on extension semantic enforcement for Kilo? 16:28:13 rkukura: neutron agent will need to configure rate limiting, it should get the required settings 16:28:44 irenab: Agreed, but I’d think the openvswitch mechanism driver would need to handle that. 16:28:51 instead of additional RPC call, it can get the details on existing call 16:29:37 irenab: I am also interested in this spec 16:29:37 irenab: Do you want to put this on the agenda for next week? 16:29:54 rkukura: I'll try to catch you offline to discuss, if its OK? 16:30:00 #action Discuss rate limiting next week 16:30:02 irenab: yes 16:30:16 rkukura: thanks 16:30:26 #action Discuss portsecurity next week 16:30:30 irenab: can you pls start a thread on the ML so others can participate/ get upto speed? 16:30:46 sadasu: Good idea 16:30:51 irenab: pls include me also if you start a thread. 16:31:10 sadasu: sure, meanwhile trying to collaborate with Sean, but will send out to ML 16:31:19 irenab: thanks 16:31:20 ML would be best, since i am interested as well 16:31:30 irenab: thanks much 16:31:48 Lets discuss on list, and summarize status at next weeks meeting 16:31:56 moving on… 16:32:07 #topic ML2 Subream Charter 16:32:44 At the weekly Neutron IRC meeting, there was discussion of subteams 16:33:22 First, should the ML2 subteam continue? 16:33:28 rkukura: I missed it because of timing - too early for me :-) 16:34:33 Layer-2 subteam rather than ML2 subteam? 16:34:54 There seems to be some movement to reduce the number of subteams, but I’m not hearing any call to eliminate the ML2 subteam 16:35:00 amotoki: Good question 16:35:03 though the main topic is related to ml2, some topics are not limited to ml2. 16:35:32 I think ML2 is still evolving, so subteam is dfntly helpful 16:35:37 amotoki: I’d think other L2 plugins are outside our scope 16:36:48 rkukura: yes to some extent.. but L2GW or other topics are related to L2. but i am not sure this is the best place to discuss. 16:36:58 Our main focus has been the ML2 plugin itself, its driver APIs, extensions, features, ... 16:37:28 rkukura: sounds reasonable 16:37:29 ML2 is the only official core plugin. rest are vendor plugins. 16:37:36 so agree with rkukura about the scope. 16:37:36 amotoki: L2GW is being proposed as a service plugin, not part of ML2 16:37:37 We’ve tried to make some progress on a modular L2 agent, but maybe that should be a separate effort 16:37:41 rkukura: Additionally, ML2 has a significant traction with respect to several vendor drivers and is very valuable resource to them 16:38:39 Should our focus be limited to the integration point, or also include the reference control plane (L2 agents, etc.)? 16:38:40 l2 agents are independent of ML2 - agree. 16:38:41 Sukhdev: i know. I am not sure what is the best approach for l2gw. I just raised potential topics to clarify the purpose of the subteam. 16:39:12 Clearly the ML2 subteam should pay attention to the l2gw effort, but I’m not sure it needs to “own” it. 16:39:26 Anyway, if we want to continue, we need a charter 16:39:28 manishg: not totally agree, since agents depend on data provided by plugin 16:39:34 but the interface should be discussed here I believe. I think all touch points will end up needing discussion here. 16:39:43 amotoki: The question is - should we limit the scope of this subcommittee to ML2 only or increase it to include all L2 related topics? 16:40:05 irenab: yes, that is the interface part. doesn't mean the architecture depends on ML2 16:40:18 Sukhdev: exactly. 16:40:22 manishg: agree 16:40:57 amotoki: I threw this question out so that we can discuss this 16:41:14 imho it is better to focus on a single topic, so focusing ML2 looks good to me. 16:41:20 I’ve started a draft charter at https://etherpad.openstack.org/p/ML2_Subteam_Charter 16:42:14 I’d suggest we try to incorporate wording on how the ML2 subteam would be involved in efforts like l2gw 16:42:46 rkukura: thanks for putting this together - this will help us focus our charter 16:42:50 I asked mestery about what he is looking for in these subteam charters 16:43:19 He’s going to put together a wiki on this, which I think will be where the charters live. 16:43:44 He did say he wanted to see goals for Kilo, so I added some of the things we’ve been discussing 16:44:24 we don’t have a lot of time left today to complete wordsmithing this 16:44:35 rkukura: I think that makes sense and it also focuses our efforts. Would be good define the charter (and thanks for the draft) 16:44:35 it is very clear definition ot me and it seems worth forming a subteam. 16:45:51 I encourage others to add their ideas and comments, and improve wording as needed 16:46:20 Does this seem like a reaonable start and a plan? 16:46:29 rkukura: yes 16:47:01 rkukura: this is a great "draft" 16:47:12 rkukura: +1 16:47:14 rkukura: yes 16:47:21 rkukura: of course yes 16:47:29 rkukura: Absolutely 16:47:38 rkukura: +1 16:47:58 OK, lets try to polish this up over the next couple days so we have something for Monday’s neutron meeting 16:48:08 next topic… 16:48:13 rkukura: I think some of the efforts maybe dictated by which direction we head towards (split of api/rpc etc.) 16:48:44 manishg: Agreed, but that’s hopefully detail that doesn’t need to be in the charter. 16:49:03 agree. 16:49:05 manishg: i think the first item covers it. 16:49:18 manishg: I am hoping nothing south of ML2 plugin changes - 16:49:22 We should try to make the charter as general and hight level as possible, covering both long term and some kilo specifics. 16:50:07 #topic ML2 driver repository discussion 16:50:09 amotoki: yes, but just saying remaining may not be completed and more stuff might come in due to the refactor. but agree with what rkukura said - make it higher level so charter doesn't change much hopefully. 16:50:52 rkukura: go ahead pls 16:50:53 I’m sure everyone is aware of the (somewhat vague) plan to move vendor drivers out of the neutron git repositroy 16:51:22 I think the initial thinking has been that each vendor would get their own (stackforge?) repo 16:51:59 That seems to make sense for monolithic plugins, and could also apply to ML2 drivers 16:52:08 rkukura: that makes more sense for monolithic plugins - I wonder if it makes sense for ML2 drivers 16:52:27 I mean individual ML2 drivers 16:52:48 But we may want to look at alternatives for keeping the ML2 drivers together, at least for those vendors that choose to do so. 16:53:28 One idea would be to have a common ml2-drivers repository, with some sort of core review team focused on ML2 16:53:38 I am assuming that unit tests will also be splt out, which begs the questions who runs the unit tests 16:53:52 Until a straw-man proposal is put together, it is hard to argue one way or the other 16:54:19 I think the main motivation for all this is that vendor drivers don’t get enough core review attention in neutron 16:54:39 armando already proposed a spec for the split. 16:54:42 #link: https://review.openstack.org/#/c/134680/ 16:54:57 manishg: thanks - hadn’t seen that 16:55:38 the spec calls for split of ml2 drivers as well, from what I remember (read it yesterday). 16:56:01 it clearly defines the parts of the vendor drivers that will stay in repo to make things easier. 16:56:17 manishg: I have not read it yet - lets all review it and post comments on the spec itself 16:56:41 Sukhdev: +1 16:57:02 rkukura: yes, that is one concern (that core reviewers won't be able to spend time on it). But I think that is the exact reason it's proposed (because they don't have the time :( ) 16:57:48 I heard the main concern as -- APIs ... if they aren't clearly defined or change frequently it maybe an issue. 16:57:54 So assuming this spec envisions moving each vendor driver into a vendor-specific repo, is there interest in a common ML2 driver repo with its own core review team? 16:58:15 I think it would be a good idea and benefit all. 16:58:39 rkukura: +1 16:58:42 at least if it is in one place other folks are more likely to review it. and we can bring up reviews here and interested folks can review. 16:58:50 My personal view is that ML2 is a long way from having a stable driver API, and trying to lock it down now to guarantee compatiblity would be premature. 16:59:01 rkukura: if it makes development/deployment/testing easier, then definitly yes 16:59:05 and vendors can learn from each other. 16:59:07 We are pretty much out of time 16:59:28 it can but if the number of vendor drivrs increases doesn't the same problem happen? 16:59:38 it is open question. 16:59:45 rkukura: versioning is proposed in the spec. 16:59:51 Lets review this spec and think about how we might go forward. 17:00:06 I guess its important to have stable API as ml2 mission 17:00:07 rkukura: I have a review for filter implementation of segments. 17:00:23 sorry... I guess no open discussion today. will bring up next time. 17:00:38 manishg: Please make sure its in the spec tracking wili 17:00:40 wiki 17:00:50 thanks everyone! 17:00:51 will add. thx 17:00:55 thanks! 17:00:57 #endmeeting