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