16:01:14 #startmeeting networking_ml2 16:01:14 hi rkukura 16:01:15 Meeting started Wed Feb 12 16:01:14 2014 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:18 The meeting name has been set to 'networking_ml2' 16:01:30 hi all 16:01:34 #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda 16:01:44 We have a very packed agenda today, lets see how far we can make it in an hour. :) 16:01:52 #topic Action Item Review 16:02:02 I just updated agenda with my AI details, so please refresh if you've got it open 16:02:05 Thanks to rkukura for sending email the binding changes. 16:02:12 can anyone fix ical feed? it told me this meeting was 2h earlier. 16:02:36 yamamoto2: I don't know how that works, maybe asking on #openstack-infra would be a good idea. 16:02:56 rkukura: Thanks for driving the discussion around the binding changes, that was pretty awesome! 16:03:00 I think there is at least one email on the thread that I haven't replied to yet 16:03:08 Yes 16:03:18 But overall, I think folks are all on the same page now it apepars. 16:03:20 Are there any reservations regarding moving forward on this in the next couple days? 16:03:31 mestery: ok, thanks 16:04:20 I've been focusing on my two BPs plus the SR-IOV work, but should start implementing the binding changes this week 16:04:28 rkukura: I'll give you an AI to move the discussion into a Google Doc, is that ok? 16:04:37 Or is that not necessary? 16:04:43 mestery: Fine, same as this week's AI 16:05:06 I think a doc makes sense for this. 16:05:09 #action rkukura to move port binding discussion into Google Doc 16:05:14 * mestery nods in agreement. 16:05:18 Any questions on the port binding discussions>? 16:05:56 no, rkukura, did you talk about my post that you didn't respond? 16:06:02 yet? 16:06:21 matrohon: I mentioned that I still need to respond. Sorry for the delay. 16:06:34 rkukura : fine, np :) 16:07:26 matrohon: Will think about that race condition and respond 16:07:47 Next AI review: prioritizing ML2 MechanismDriver BPs. 16:08:01 So, the feature freeze is this coming Teusday I believe. 16:08:11 People need to propose their MDs by then to have a shot of getting them into Icehouse. 16:08:18 And the 3rd party testing requirement must be met as well. 16:08:30 I haven't changed any priorities, but I summarize status of the 12 MD BPs in the agenda. 16:08:53 Thanks rkukura. 16:08:54 I'd like to discuss the ones that have question marks at this meeting if we can. 16:09:02 Now or later in the agenda? 16:09:02 Please do! 16:09:14 Lets do it now. 16:09:18 mestery: 2/18 is a code deadline, not a bp deadline, right? 16:09:34 First, there are two from bigswitch 16:09:43 asadoughi: right. precisely speaking the feature freeze is I-3. Next tuesday is the deadline to propose the code of blueprints. 16:09:43 I think 2/18 is feature freeze: https://wiki.openstack.org/wiki/Icehouse_Release_Schedule 16:09:51 https://blueprints.launchpad.net/neutron/+spec/bsn-ml2-mechanism-driver - medium, approved, no review, no jenkins? 16:09:57 regarding FSL-SDN Mechanism Driver BP, I'm working on 3rd party test setup. sent a mail to opestack-infra on gerrit account.. waiting for reply. Done with code improvements. need to commit the code for review. 16:10:03 mestry - we are working on making some enhancements to Arista MD. next week's deadline does not apply to that, right? 16:10:04 https://blueprints.launchpad.net/neutron/+spec/bigswitch-ml2-driver - low, approved, in review, no jenkins?, relationship to bsn-ml2-mechanism-driver? 16:10:22 mestery: no i think it's what amotoki_ said 16:10:51 iIs netwt week dead line applicable for our MD.. FSL-SDN 16:10:53 ?? 16:10:54 asadoughi: You are correct, it's feature proposal freeze. If you haven't pushed code for your BP by 2-18, it won't be considered for Icehouse. 16:11:01 Both of these are approved and have reviews linked. Are these two different drivers? And is a jenkins job in the works? 16:11:03 trinaths: Yes 16:11:23 trinaths: You need to have pushed code by next Tuesday, it doesn't have to be complete. 16:11:58 mestery: I have the code in place for review 16:12:16 trinaths: OK, if it's pushed out, you are ok for FPP on 2-18. 16:12:25 all the CI's give +1, but jenkins gives -1 16:12:45 so woking on code improvements and 3rd party test setup 16:12:59 Sounds like we've covered: https://blueprints.launchpad.net/neutron/+spec/fsl-sdn-os-mech-driver - low, approved, in review, no jenkins? 16:13:05 OK, thanks trinaths. 16:13:20 Its at low, so should be bumped to medium as soon as the jenkins job is in place 16:13:28 yes rkukura.. I have submitted the code for review and improving the same' 16:13:47 Anyone from BigSwitch here? 16:13:51 does Jenkins job mean our 3rd party test setup 16:14:03 trinaths: yes 16:14:05 mestery: can you answer my question, please? 16:14:28 Sukhdev: Sorry, missed your question due to mispelling my name :P 16:14:38 So, any code which has a shot at Icehouse needs to be proposed by 2-18. 16:14:40 In some form. 16:14:41 Even WIP. 16:14:47 sukhdev: it is new code, so the deadline does not apply to you 16:14:49 If it's not proposed by 2-18, it won't make Icehouse is my understanding. 16:14:59 since I have jenkins job in pending state, can my driver cross the 218 deadline?? 16:15:02 Bug fixes are ok I guess poast that right? 16:15:06 even code being pushed up labeled as bugs 16:15:15 bugs are ok past that, sorry for the confusion :) 16:15:19 bug fixes are OK past this deadline 16:15:21 I meant BP code. 16:15:29 * mestery drinks some more coffee. 16:16:02 since I have jenkins job in pending state, can my driver cross the 2-18 deadline?? 16:16:11 mestery: well put. it is BP code. 16:17:03 Thanks shivharis. 16:17:05 trinaths: I think you are OK with 2/18 since you have code in review. Just need the jenkins job. 16:17:21 okay rkukura.. thank you 16:17:39 mestery: so, to be clear - since we are making enhancements to older code, this dead line is not applicable to us. We can submit a bug and code at a later date, right? 16:18:11 Sukhdev: If it's a bug, it's ok past 2-18. 16:18:23 rkukura: Regarding https://blueprints.launchpad.net/neutron/+spec/ml2-opendaylight-mechanism-driver 16:18:36 Code is proposed, waiting on Linux Foundation for 3rdp arty testing. 16:18:39 Sukhdev: The challenge will be to get core reviewers to pay attention later in the cycle 16:18:42 Hopefully next week we get that up and running. 16:18:45 mestery: thanks for clarification 16:19:46 Any other updates for the remaining MDs with question marks? 16:19:47 Do all the cisco MDs get tested by the current cisco jenkins job? 16:20:09 rkukura: that will be the case soon 16:20:20 HenryG: OK, thanks 16:20:44 Anyone know if there are BigSwitch and/or Huawei jenkins jobs in the works? 16:21:20 I have seen Bigswitch CI 16:21:57 as far as I looked so far, it seems big switch CI works 16:21:57 testing my code 16:22:10 regarding https://blueprints.launchpad.net/neutron/+spec/ml2-ucs-manager-mechanism-driver - medium, approved, no review, have jenkins? 16:22:38 will have code shortly..before 2/18...jenkins before march 6th 16:22:47 have dependency on 3 other BPs 16:22:54 I see it on some reviews, so I guess its OK. Seems to be missing from https://review.openstack.org/#/c/72452/ 16:23:16 ok 16:23:51 I think we've covered everything we can 16:23:54 thanks! 16:23:58 thanks rkukura! 16:24:11 #topic ML2 Exceptions to UserSpace 16:24:20 This is in reference to this bug: https://bugs.launchpad.net/neutron/+bug/1273730 16:24:43 There was some pushback in the review, I think it's worth discussing this here, right rkukura? 16:25:01 sure 16:26:03 OK, hadn't seen latest comments 16:26:38 So, it appears armax was recommending pushing this to Juno, the author of the patch appears to have agreed. 16:26:41 I kind of like the idea of storing exceptions in port attributes 16:26:46 the push back seem cosmetic at this stage. 16:27:16 format of the error message (of course collecting all messages was taken care of by paul ward) 16:27:50 shivharis: I think comments from armax appear to indicate this should be refactored, right? 16:27:59 I think it can be argued that normal users should not see details that expose the internal implementation choices of the cloud 16:28:02 shivharis, armando's comment was interesting and ... what mestery said 16:28:22 Yes, I agree with what rkukura and armax say there. 16:28:35 Are we currently logging the detailed exception? 16:28:55 If so, the admin can track it down if necessary. 16:28:59 you'd need to look at all md's to get that answer 16:29:14 rkukura: the detail is logged. https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py#L159 16:29:47 Shouldn't the MechanismManager be logging the caught exception, then raising the generic one? 16:29:57 mestery: i just read that comment. 16:30:07 amotoki_: thanks 16:30:27 Somewhat related; not essential but something we need to have at some point: Deals with fails in update-*-postcommit ops https://review.openstack.org/#/c/69792/ 16:30:38 note that the managers.py LOG doesn't give you any real depth of what the md exception was 16:31:34 rcurran: Doesn't LOG.exception( 16:31:37 _("Mechanism driver '%(name)s' failed in %(method)s"), 16:31:39 {'name': driver.name, 'method': method_name} 16:31:41 ) give enough depth? 16:32:03 doesn't that just give you the method name that caught the excep 16:32:26 what if there are multi exception types on one method 16:32:35 I thought LOG.exception logged the actual exception, but could be wrong 16:32:39 we seem to all agree that err messaging needs to be enhanced, but it should not hold other things up. 16:33:13 I do like the proposal to but the detailed error info in an admin-only port attribute 16:33:34 hopefully adding the arguments of the method to log messages will help admin to debug. 16:34:03 amotoki_: Do you mean like everything in the PortContext? 16:34:45 what i mean is adding these infomration to the log message for MD exception. 16:35:25 At now i cannot say it applies to all PortContext. 16:36:19 Should we move this discussion back to the jenkins review, and try to agree on what's needed for icehouse vs. longer term? 16:36:56 I think so. 16:37:00 * HenryG agrees 16:37:19 agree 16:37:21 OK, moving on in the agenda. 16:37:26 yeah, i think most engs are leaning towards the longer term approach 16:37:37 * mestery agrees with rcurran. 16:37:40 #topic BPs 16:37:51 First up: Provider network partial specs: https://wiki.openstack.org/wiki/Provider-network-partial-specs 16:37:58 Addressed by review https://wiki.openstack.org/wiki/Provider-network-partial-specs 16:38:21 Is zzelle here? 16:38:29 yes, here i am ! 16:38:37 zzelle: Hey, howdy! 16:38:47 fine 16:38:56 So, can you walk us through the high level thinking here? 16:39:42 currently, you have tenant network, neutron is in charge of network attributes choice 16:39:47 mestery: Do you have the link to the actual review? 16:39:59 rkukura: Sorry, yes: https://review.openstack.org/#/c/71904/ 16:40:26 you have provider netowkr, neutron admins are in charge of attributes choice 16:40:54 the aim is to allow to delegate some provider network attributes choice to neutron (when possible) 16:41:40 typically, you need a vlan network, you do neutron net-create myvlannet --provider:network_type=vlan 16:41:56 and neutron tries to find in a pool a valid network 16:42:49 IMHO, the feature could used when deploying networks for baremetal/appliances 16:43:15 you want to add a provider pool? 16:43:20 So, the idea is to not require provider:physical_network and provider:segmentation_id when creating provider networks? 16:43:28 And use the normal tenant pool or some new pool as matrohon says? 16:43:51 matrohon, currently in the review i reuse tenant pools 16:44:11 but salv proposes to use a specific one, but it implies to change the datamodel 16:44:20 This kind of touches on an area from the original ML2 proposal that has not (yet) been implemented. The tenant_network_types config is a list, with the intention that TypeDrivers are tried until one can allocate the network. We eventually wanted some generic QoS requirements that users could specify that would influence which TypeDriver was chosen. Basically TypeDrivers would ignore the request if they couldn't 16:44:23 provide the QoS. 16:45:41 so my proposal was first to reuse tenant pools, and after allow to specify a provider (only) one 16:46:40 Idea has definite merit, beginning to think this should be post I3. 16:46:42 rkukura, good to know, the aim of this feature is more pragmatic 16:47:30 i only provide the support for vlan networks because i don't see usecase for other network types 16:47:52 but supporting other network types is quite simple 16:47:54 Is this still admin-only, or would the policy.json have to allow normal users to specify the providernet attrbutes? 16:48:29 +1 for post-I3 with independent pool, to have something clearer in the conf files 16:48:33 still admin-only because it concerns provider networks 16:49:37 in practice, the feature is implemented through an alternative vlan type driver implementation 16:50:06 So, is the consensus for this we need the separate pool, which would push this to Juno then? 16:50:08 I'm kind of favoring using the existing TypeDrivers and pools, but just making provider network allocation able to use the pool to fill in the unspecified details (vlan) 16:51:03 To me, this is a relaxation of the current provider network restriction, not a new tenant network 16:51:38 I think so. 16:51:42 Plus, the reservation of the VLAN tag on a physical_network for this has to make that tag unavailable for normal tenant network allocation 16:51:45 i think reusing tenant pools is still useful. For example admin can create a net only with network_type (and phys_net). 16:52:28 OK, so maybe we approve this one for Icehouse then as-is? Is that what I'm hearing? 16:52:33 The use case is compelling I think. 16:53:20 fine :) 16:53:30 Maybe a config option for VlanTypeDriver is all that's needed - it would just use the pool when provider:network_type is specified but the other data isn't specified. 16:53:44 do i provide the support only for vlans ? 16:53:55 zzelle: That makes sense to me. 16:54:06 OK, we only have 7 minutes left now. 16:54:09 or does it makes sense to provide for others network types ? for testing ? 16:54:19 vxlan ang gre would be nice toot 16:54:22 Lets continue this discussion on the review and ML. 16:54:23 s/provide/porivde it/ 16:54:38 I don't see a lot of use for provider tunnels as long as the neutron server is doing the endpoint management 16:54:42 rkukura: are you still suggesting using the existing type driver and folding this functionality in it? 16:54:45 I wanted to give matrohon 5 minutes or so for his agenda item (we'll have to skip a few other items). 16:54:58 fine 16:55:01 rkukura: That's what I'd prefer. I'll comment in the review. 16:55:06 #topic Multi-Node Testing 16:55:13 With 5 minutes left, I give the floor to matrohon. 16:55:23 s/rkukura/shivharis/ 16:55:38 so we would like to enable mutli-node in the gate 16:56:06 to improve test on ovs/lb/l2-pop MD 16:56:21 Makes sense to me matrohon 16:56:47 matrohon: +1 16:57:18 jgallard, doude and I are working on a gate to manage multi-node with lxc 16:57:34 matrohon: Sounds very interesting! 16:57:36 nice 16:57:46 but we should first write a BP in openstack-infra 16:58:19 we need your help to have infra team focusing on this issue 16:58:54 this would be needed for live-migration test too 16:59:15 matrohon: Agreed. 16:59:32 So, I would suggest filing the BP and bringing it up at the infra meeting this week (or next if it's already happened this week). 16:59:44 But this is a good thing to have, so thanks for taking this on! 16:59:56 ok I tak ethe AI 17:00:01 matrohon: the nodes themselves are lxc? Or the instances in the nodes? 17:00:10 I am not sure which is better infra or QA. 17:00:15 #action matrohon to file BP for multi-node testing and bring this up in the infra meeting 17:00:20 And with that, we're out of time folks. 17:00:24 quick ovs-firewall-driver update: moving bp to juno since dependent ovs release won't be released until march https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver 17:00:26 mestery: indeed :p 17:00:28 Thanks for all your efforts on ML2 everyone! 17:00:37 Thanks asadoughi, apologies we ran out of time. :) 17:00:38 #endmeeting