16:03:57 <rkukura> #startmeeting networking_ml2
16:03:59 <openstack> Meeting started Wed Dec  3 16:03:57 2014 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:02 <openstack> The meeting name has been set to 'networking_ml2'
16:04:18 <rkukura> #topic: Agenda
16:04:34 <rkukura> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Agenda
16:05:19 <rkukura> #topic: Announcements
16:05:40 <rkukura> Mid-cycle meetup: https://wiki.openstack.org/wiki/Sprints/NeutronKiloSprint
16:06:11 <rkukura> looks like ML2 will be well-represented at this
16:06:18 <Sukhdev> I noticed 4 ML2'ers have signed up for the sprint
16:06:44 <rkukura> Anyone going that’s not on the wiki?
16:06:47 <banix> Sukhdev: good
16:06:58 <Sukhdev> banix: how about you?
16:07:06 <Sukhdev> banix: missing this time?
16:07:06 <shivharis> maybe for me
16:07:09 <banix> Sukhdev: cannot make it I am afraid
16:07:23 <Sukhdev> shivharis: sign up please
16:07:37 <rkukura> Looks like all the agenda is relevant to ML2
16:07:42 <irenab> hi, sorry for being late
16:08:01 <banix> rkukura: yes, good that there are ml2’ers there
16:08:26 <shivharis> Sukhdev: need to figure out a customer visit, will know shortly
16:08:28 <rkukura> Since both Sukhdev and will be at this next week, we’ll skip the IRC meeting unless someone else wants to chair it
16:09:09 <rkukura> And we can discuss the meetup at the following week’s ML2 meeting
16:09:24 <asomya> what are some of the work items for ML2 at the mid cycle sprint?
16:10:10 <rkukura> asomya: I believe the API/RPC layer refactor and Core Plugin refactor will both have big impact on the plugins, especially ML2
16:10:46 <asomya> Will this be a good opportunity to address some of the proposed type driver refactor things we discussed in Paris?
16:11:03 <asomya> Or should we do that after this sprint?
16:11:29 <rkukura> asomya: I’m sure there will be some opportunities to talk about that sort of thing, but I think the focus of this is a “code sprint”
16:11:55 <asomya> rkukura: sounds good, i was debating whether to go for the sprint or not
16:12:33 <rkukura> One concern i have is that I think the plan is (still?) to move all the existing extensions into the core API, and I’m not sure it will be possible for ML2 extension drivers to still add additional extensions
16:12:50 <Sukhdev> asomya: i think you should attend, if you can afford to go
16:13:04 <asomya> sukhdev: I'll try :)
16:13:29 <rkukura> It would be useful to know what ML2 mechanism drivers require vendor-specific core resource extensions
16:13:33 <banix> rkukura: i think at least on the spec that is posssible
16:14:28 <rkukura> banix: OK, good to know
16:14:41 <rkukura> anything else on the meetup?
16:15:04 <rkukura> Sub-teams charter https://wiki.openstack.org/wiki/NeutronSubteamCharters
16:15:42 <sadasu> port security extension and the rate limit extension that irenab brought up?
16:15:44 <banix> we need to add an End Goal section
16:15:46 <rkukura> So I added the text from our etherpad to this, but we need to link the BP specs we are tracking during kilo
16:16:10 <sadasu> rkukura: I was still trying to answer your question on the previous topic!
16:16:15 <rkukura> banix: Not sure all teams need end goals?
16:16:18 <Sukhdev> banix: please elaborate?
16:16:46 <banix> Sukhdev: rkukura there is a new section added to the template called End Goal
16:17:03 <rkukura> sadasu: Right - I’m a strong believer in exensibility as a facilitator for innovation
16:17:15 <shivharis> ml2 maybe an ongoing topic, so what does endgoal mean here?
16:17:24 <banix> End Goal (When Are you Done?) Long lived sub-teams with no clear charter are bad. You should have a goal, a timeline, and a completion date in mind.
16:17:34 <rkukura> I guess we could say we have a clear charter instead
16:18:00 <rkukura> Do we think we’ll be done at some point?
16:18:11 <Sukhdev> rkukura :-)
16:18:29 <banix> rkukura: all good things will come to an end :)
16:18:43 <rkukura> banix: OK, will we be done before neutron is done?
16:18:43 <banix> rkukura: but i understand your point
16:18:51 <banix> rkukura: exactly
16:19:09 <rkukura> I guess we could have a goal of eventually stabilizing the ML2 driver APIs and/or folding ML2 into the neutron core
16:19:12 <sadasu> if one release goes by with no changes to core ML2 plugin, then can we say  that it has stabilized and "Done" /
16:19:37 <irenab> sadasu: +1
16:19:49 <rkukura> sadasu: OK, I’ll add something along those lines
16:19:52 <sadasu> rkukura: +1
16:20:16 <rkukura> Kilo release schedule: https://wiki.openstack.org/wiki/Kilo_Release_Schedule
16:21:12 <rkukura> So kilo-1 milestone is in 15 days, kilo-2 in February
16:22:18 <rkukura> More critical, the SPD is this coming Monday!
16:22:19 <sadasu> rkukura: only critical ml2 driver fixes would be merged until the split happens, corrcet/
16:22:41 <Sukhdev> sadasu: that is my understanding
16:23:01 <rkukura> sadasu: I’m not sure about that, but we’ll discuss the split in a bit
16:23:12 <banix> sadasu: Sukhdev hmmmm how come?
16:23:23 <rkukura> I’m should have the updated HPB spec submitted later today
16:23:35 <sadasu> that is what the split BP states
16:23:56 <Sukhdev> banix: based upon what is written in https://review.openstack.org/#/c/134680/
16:24:04 <banix> got it thanks
16:24:33 <sean-k-mooney> the split bp has not been merged /approved yet but yes that was its recomendation
16:24:49 <banix> yes we need to review it
16:25:04 <banix> i think that was one of the action items (uncalled) for the week
16:25:26 <rkukura> banix: agreed, and this is something that will probably become a concrete plan next week at the sprint
16:25:30 <Sukhdev> banix: I have been asking for all ML2'er to review it and post your comments
16:25:56 <sadasu> rkukura: yes, waiting to hear what decisions are made next week
16:26:11 <banix> Sukhdev: i know; dont see many though (myself included)
16:26:40 <rkukura> lets all try to review that spec this week and get comments in
16:27:13 <sadasu> rkukura: confusing part is, are mech driver BP specs going to be reviewed by cores?
16:27:17 <rkukura> So, spec proposal deadline is Monday - all specs need to be submitted for review by then
16:27:55 <rkukura> sadasu: I don’t know
16:27:56 <Sukhdev> sadasu: correct. I believe that is true for K cycle
16:28:55 <rkukura> Other than HPB, what other specs are planned for Kilo that haven’t been submitted yet?
16:28:59 <Sukhdev> sadasu: even I found it bit confusing - but, this requirement will go away in L-cycle
16:29:14 <asomya> rkukura: I have to submit a spec for the refactor
16:29:27 <shivharis> I have a new mech driver that will be submitted today
16:29:31 <Sukhdev> asomya: please submit ASAP
16:29:34 <rkukura> Lets assume for now that vendor drivers need specs in kilo
16:29:38 <asomya> will do today
16:29:41 <sadasu> Sukhdev: correct.
16:29:50 <irenab> rkukura: Ml2 extension for port rate limit spec will be subbmited soon
16:30:08 <rkukura> any others?
16:30:22 <Sukhdev> 12/8 is the deadline for all specs to be in...
16:30:26 <sean-k-mooney> i submitted a spec for a new mech dirver an hour ago too.
16:30:26 <irenab> also just submitted https://blueprints.launchpad.net/neutron/+spec/network-settings-support-vnic-type
16:30:39 <rkukura> and 12/15 is the deadline for them to be approved
16:30:52 <rcurran> vxlan support for cisco nexus (dep on HPB and asomya's type driver)
16:31:31 <sadasu> here is a link to my mech driver spec: https://review.openstack.org/#/c/134056/
16:31:35 <rkukura> #action everyone Submit kilo specs for review by 12/8, but ASAP since approval deadline is 12/15
16:31:47 <sadasu> I have a few +1s already
16:31:50 <rkukura> Do we want to continue tracking these via the wiki?
16:32:01 <sadasu> thanks to those who reviewed...you know who you are
16:32:06 <shivharis> rkukura: +1
16:32:10 <rkukura> If so, it needs updating so that the top section is the actual kilo specs
16:32:10 <irenab> rkukura: yes
16:32:53 <Sukhdev> rkukura: banix and I used to baby sit that wiki :-)
16:32:55 <rkukura> #topic bugs
16:32:56 <sean-k-mooney> i added the link to mine  https://review.openstack.org/#/c/138742/ to the wiki too but was not sure if it is still used
16:33:08 <rkukura> #undo
16:33:09 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x3db0210>
16:33:28 <rkukura> Does anyone want to take an action to cleanup/reorganize the tracking wiki?
16:33:39 <manishg_> I'll take it
16:33:44 <banix> i tried to go through them a week or so ago but it may not be up to date
16:33:54 <banix> manishg_: thanks
16:33:57 <Sukhdev> If the team believes it is useful, we can continue to maintain it
16:34:02 <shivharis> I'll take joint ownership
16:34:19 <rkukura> #action manishg_ Cleanup and reorganize https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
16:34:21 <banix> mainly, the owners of bps, need to keep it up to date
16:34:46 <rkukura> #undo
16:34:47 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x3ac0350>
16:34:50 <Sukhdev> manishg_, shivharis: you have to ensure that it is up-to-date
16:35:04 <sadasu> banix: manishg: will update with mine
16:35:09 <shivharis> Sukhdev: +1
16:35:10 <rkukura> #action manishg_ and shivharis: Cleanup and reorganize https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
16:35:24 <manishg_> Sukhdev: +1
16:35:28 <banix> sounds good
16:35:30 <rkukura> OK, I think we covered the spec reviews topic, lets go back to bugs
16:35:33 <rkukura> #topic bugs
16:35:34 <manishg_> sadasu: thanks.
16:35:44 <rkukura> shivharis: any update on this?
16:35:46 <shivharis> Hi
16:36:18 <shivharis> This is going to be fun. Since we are only going to get critical bugs in
16:36:37 <shivharis> and since we have no "critical" bugs we are done --- (just kidding)
16:36:51 <rkukura> shivharis: Why only critical bugs?
16:37:22 <shivharis> Only critical bugs will be entertained for merge .(that is what i hear)
16:37:33 <shivharis> However...
16:37:56 <rkukura> shivharis: Is that for vendor drivers/plugins, or everything?
16:37:56 <shivharis> We hav 56 bugs, and many in medium and low.
16:38:24 <shivharis> Early in a cycle it is good to help onboard new team members
16:39:02 <shivharis> I would like folks to look at the bugs and please pick up these bugs (that get sidetracked) at the end of the tail end of the release
16:39:17 <shivharis> rkukura: everything
16:39:42 <shivharis> Also it would be nice to have a list of primary maintainers of vendor plugins
16:40:14 <shivharis> So please help out in picking up these bugs, some maybe low hanging fruit
16:40:17 <banix> regarding #link https://review.openstack.org/#/c/113999/ looking at logs from a few weeks ago (when i was absent) it was mentioned i think by rkukura that we may not need the bug fix for bulks if the tasks stuff get done… the patch is almost there, almost got merged ;) at Juno RC1 and now need a rebase and addressing yamamoto ’s comments. should i get that done or simply abondon?
16:40:21 <sean-k-mooney> if im not mistakend dont all vendor plugins require a point of contact?
16:41:00 <banix> sean-k-mooney: their CI systemdoes
16:41:16 <shivharis> sean-k-mooney: yes, but this is not done completely
16:41:35 <irenab> what about not vendor specific, like OVS, LB, SRIOV?
16:41:41 <shivharis> We have vendor bugs sitting in q for a very long time
16:41:50 <sean-k-mooney> banix: thanks
16:41:57 <shivharis> So, please help out here.
16:41:59 <rkukura> banix: Lets see what happens at the meetup next week regarding the plugin APIs, and then decide whether to go with the proposed fix or not
16:42:09 <shivharis> I am looking for new volunteers
16:42:13 <banix> rkukura: ok
16:42:26 <rkukura> I’ve been out of the loop lately, but cannot believe bug fixes are not being merged
16:42:38 <manishg_> shivharis: should the vendors not be fixing their own bugs?
16:43:11 <manishg_> if the vendors don't care I wonder if should give them lower priority as compared to other bugs.
16:43:20 <shivharis> vendors usually fix their own bugs - but since it becomes community code anyone can jump in
16:43:58 <manishg_> yeah they can jump in but in ML2 community should we first take care of other more important stuff?
16:44:03 <shivharis> i am not seeing volunteers, so i will have to start assigning
16:44:27 <shivharis> moving on
16:44:32 <shivharis> https://review.openstack.org/#/c/113999/
16:44:33 <manishg_> I'll pick some of them but let's not assign vendor bugs unless someone really wants to.
16:44:40 <shivharis> banix: ?
16:44:49 <banix> shivharis: thanks i already jumed the gun as usual
16:45:11 <banix> wondering whether to work on it or not; rob suggesting wait until next week which sounds reasonable
16:45:27 <shivharis> ok
16:45:39 <rkukura> banix: My view is that we’ll likely go with this fix, but lets see what impact the plugin API changes has
16:46:02 <banix> rkukura: sure; meanwhile i rebase and address yamamato’s concern
16:46:03 <shivharis> manishg_: I will try to assign the vendors specific bugs to relevant folks they may re-assign
16:46:18 <shivharis> that is all I have for bugs
16:46:19 <rkukura> banix: make sense to me
16:46:25 <rkukura> shivharis: thanks
16:46:25 <manishg_> shivharis: thanks
16:46:41 <rkukura> #topic driver repo discussion
16:46:48 <rkukura> we already discussed this a bit
16:47:33 <rkukura> I don’t yet fully grasp the current proposal - still need to read it in detail
16:47:57 <rkukura> But I get the impression the drivers themselves stay in the neutron repo. Is that correct?
16:48:17 <banix> rkukura: no just a thin part of them
16:48:31 <sean-k-mooney> the ovs mech drive will at least but i belive the rest are moved out
16:48:34 <rkukura> That thin part is what I meant by “the drivers themselves"
16:48:35 <banix> rkukura: that will interface with the out of tree piece
16:48:46 <banix> rkukura: yes then :)
16:48:54 <manishg_> rkukura: no drivers move out.  except ovs (as sean-k-mooney said) - initially.  later that moves out too.
16:49:09 <manishg_> s/no drivers/no, drivers/  :)
16:49:32 <rkukura> so there is not thin peice remaining in tree, not even the driver entry point?
16:49:47 <sadasu> rkukura: db, config and requirements.txt stays in tree for each driver
16:49:51 <rkukura> s/not/no/
16:50:00 <rkukura> does this make sense to anyone?
16:50:03 <sadasu> rkukura: all other code lives outside the tree
16:50:43 <sadasu> rkukura: all other code -> all other mech driver code
16:51:27 <shivharis> how will tempest/unit tests run?
16:51:28 <banix> when i refered to a thin part staying in tree that was for mono plugins
16:51:37 <irenab> also agent entry point is kept in the tree
16:51:45 <sadasu> requirements.txt points to the outside repo where driver code lives and also specifies other packages that the driver needs to import etc
16:52:07 <sadasu> irenab: correct
16:52:55 <rkukura> I’m concerned its going to become extremely difficult to evolve the driver APIs with this plan
16:53:33 <rkukura> We are running short on time. Lets all review the spec and get our comments in.
16:53:33 <shivharis> I believe we will need some example drivers to remain in
16:53:44 <irenab> I guess as ML2 subteam we may propose some way to support ML2 pieces (Mech. and Extension Drivers)
16:54:00 <sean-k-mooney> i belive the intention is to keep the ovs driver for the gate and as an example
16:54:10 <amotoki_> how can we version the driver API? I think we need to consider some versioning for internal APIs.
16:54:29 <amotoki_> it is not achieved in the plugin API yet.... :-(
16:54:59 <rkukura> amotoki_: Are you suggesting that we make ML2 support multiple driver API versions simultaneously? That would add significant complexity!
16:55:42 <amotoki_> rkukura: at least,  if we support two versions, out-of-tree drivers can migrate to new API .
16:56:02 <amotoki_> but i understand it is not an easy thing of courses.
16:56:40 <sean-k-mooney> amotoki: would we then evolve the api in lockstep over each cycle depreacting the older api
16:57:03 <rkukura> amotoki_: I’m not sure this whole approach is worth it. I’d much rather see the drivers stay in tree, but be made as thin as possible wrappers around external libraries that deal with the backends.
16:57:30 <rkukura> only 4 minutes left
16:57:33 <Sukhdev> sorry - I lost power at my home
16:57:37 <Sukhdev> I am back now
16:57:39 <sadasu> rkukura: +1
16:57:43 <banix> before running out of time, note the l2 agent work may have some implications as well; review the proposal pls https://review.openstack.org/#/c/137808/
16:57:44 <amotoki_> rkukura: it is just an idea, but I don't have a good concrete plan right now.
16:57:48 <rkukura> #topic Modular L2 agent
16:58:06 <sadasu> I was hoping that the split would slice it that way, but it isn't
16:58:16 <banix> #link https://review.openstack.org/#/c/137808/
16:58:16 <rkukura> amotoki_: makes sense in theory
16:58:48 <banix> l2 improvement spec ^^^
16:58:52 <manishg_> rosella already put a spec out.
16:58:59 <manishg_> banix: thanks.
16:59:20 <rkukura> So is this something the ML2 team should track through kilo?
17:00:10 <banix> not sure
17:00:12 <rkukura> And is any “modularity” being proposed, or is that something we’d pursue seperately?
17:00:26 <manishg_> Looks like currently it's going on independently.  I may be helping with it.
17:00:44 <banix> rkukura: no modularity; was asked to postpone
17:01:02 <rkukura> ok
17:01:02 <rkukura> we are out of time
17:01:02 <rkukura> thanks everyone!
17:01:09 <manishg_> thanks.
17:01:10 <banix> bye
17:01:10 <rkukura> #endmeeting