16:02:15 <rkukura> #startmeeting networking_ml2
16:02:16 <openstack> Meeting started Wed Apr 16 16:02:15 2014 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:19 <openstack> The meeting name has been set to 'networking_ml2'
16:02:43 <rkukura> #topic Announcements
16:03:10 <rkukura> congrats to mestery on being elected PTL!
16:03:32 <mestery> Thanks rkukura!
16:03:34 <banix> congrats! :)
16:03:39 <amotoki> congrats mestery.
16:03:52 <emaganap> rkukura: +1
16:03:53 <Sukhdev> mestery: Huge contratulations!!!
16:04:00 <rkukura> since that is more than a full time job, Sukhdev has volunteered to take over as a co-chair of our sub-team
16:04:06 <rkukura> thanks Sukhdev!
16:04:17 <mestery> Thanks Sukhdev for volunteering!
16:04:30 <Sukhdev> My pleasure!!
16:04:45 <banix> cool! :)
16:04:52 <rkukura> So the co-chair role is mainly to facilitate these weekly meetings and report sub-team status at the neutron IRC meeting
16:05:57 <trinaths> mestery: congratulations
16:06:25 <rkukura> Hopefully at least one of us will be available each Wednesday, but others could certainly step in if needed
16:07:01 <rkukura> Its everyone’s job to review code, blueprints, and docs related to ML2
16:07:14 <rkukura> any other announcements?
16:07:38 <rkukura> I don’t see any action items recorded from last week
16:08:12 <nlaouti> the was some VDP discussion last week can we discuss it now
16:08:20 <rkukura> #topic TypeDriver Refactoring
16:08:44 <trinaths> can we start submitting the BPs into the review system (the new process)
16:08:46 <rkukura> I don’t see asomya here, so we may have to push this off again
16:08:55 <rkukura> trinaths: Definitely!
16:09:00 <Sukhdev> rkukura: I thought mestery was going to arrange Asomya to come and present
16:09:06 <rkukura> should have mentioned that in annountments
16:09:06 <asomya> rkukura: I''m here
16:09:17 <nlaouti> we just open new BP https://blueprints.launchpad.net/neutron/+spec/vdp-network-overlay
16:09:19 <rkukura> asomya: great!
16:09:41 <nlaouti> to address the > 4k seg and changes in ovs_neutron agent
16:09:58 <asomya> I've managed to refit ML2 and almost all type drivers, had to take a two week break due to some personal stuff but i'm confident i'll be able to push at least a WIP this week or next by the latest
16:10:02 <rkukura> nlaouti: lets cover that under the design summit sessions section of the agenda
16:10:26 <nlaouti> It has it
16:10:27 <rkukura> asomya: Are you planning to submit a summit session on this?
16:10:34 <nlaouti> paddu can give the link
16:10:55 <padkrish> #rkukura# Here the link for that http://summit.openstack.org/cfp/details/314
16:10:59 <asomya> Weren't you rolling all these into one ML2 session?
16:11:04 <asomya> I can do a quick demo
16:11:17 <asomya> don't think i have anough material for a dedicated session :)
16:11:31 <rkukura> OK, lets include that in a catch-all session that I’ll file
16:12:10 <rkukura> Does this work effect the way providernet and/or multiprovidernet extensions are used with ML2?
16:12:10 <Sukhdev> asomya: it is on the same lines that you presented in HongKong?
16:12:29 <asomya> sukhdev: Yes it's the same BP
16:13:04 <rkukura> OK, I’ll inlcude the link the the existing BP in the catch-all session proposal
16:13:37 <padkrish> #asomya#: Last week there was a talk about dynamic VLAN allocations. Is there a BP for that?
16:13:45 <rkukura> My understanding is that all BPs will need to go through a review/acceptence process in the new neutron-specs repo.
16:14:02 <Sukhdev> asomya: you had a specific use case padkrish has a specific use case rkukura had proposed last week that we come up with a generic mechanism in ML2 to deal with this
16:14:37 <asomya> Sukhdev: Padkrish: Yes that's my goal after the architecture changes to author a custom vlan type driver. We can sync up and see if we can make it generic enough to be reusable
16:14:58 <rkukura> padkrish: I’m going to propose a session and BP on a base mechanism for dynamic VLAN assignment, and I think the stuff you and nlaouti are talking about would build on that
16:15:23 <nlaouti> does it mean the costum vlan type driver can support more that 4k segment?
16:15:26 <rkukura> Any other questions for asomya right now re. type driver refactoring?
16:15:39 <Sukhdev> rkukura, padkrish, asomya: we should coordinate this work
16:15:52 <asomya> nlaouti: Yeah, that's the goal
16:16:16 <nlaouti> asomya: that's good
16:16:20 <padkrish> #sukhdev# Sure, how can we do that? Thru the dev mailing list?
16:16:42 <asomya> Rkukura: Is the custom driver part of the ML2 catchall session? or we can have an unconference session
16:16:47 <amotoki> I have another use case. point-to-point link between VM vnics (without mac learning), though it seems orthogonal to the exsting type drivers.
16:16:49 <Sourabh> I have a question - N1k plugin has an extension called network profile - it allows specifying custom segment ranges and segment types for a network - can we do this with your refactoring?
16:16:54 <Sukhdev> padkrish: can we kick off discussion on ML and then if the need be, we can arrange a meeting
16:17:16 <rkukura> Lets cover the dynamic VLAN stuff in the design summit session agenda topic in a bit
16:17:21 <mestery> asomya: I think they killed the unconference slots this year.
16:17:32 <rkukura> #topic ovs-firewall-driver update
16:17:43 <asadoughi> hi
16:17:50 <rkukura> asadoughi: any update for us?
16:18:06 <rkukura> We didn’t cover that last week, did we?
16:18:09 <asadoughi> so still working on restoring existing patches, vthapar is out on vacation this week
16:18:43 <asadoughi> still attempting to have a working impl by summit but my short term schedule hasn't been as open as i expected
16:19:03 <rkukura> asadoughi: Are you submitting a session proposal for this?
16:19:09 <asadoughi> that's all. i have feedback on one of the patches i restored that i need to get to already.
16:19:16 <asadoughi> rkukura: yes, already submitted
16:19:19 <vthapar> one small update from me, I've shared some of my prototype reflexive learning code with my test team and once they have resources available will be testing out OVS2.1's 200k flow space.
16:19:38 <asadoughi> vthapar: coo
16:19:40 <asadoughi> l
16:19:48 <mestery> vthapar: Cool, that sounds pretty awesome!
16:20:17 <vthapar> I had one question regarding use of openvswitch...
16:20:39 <vthapar> is the planned future direction to reduce no. of bridges in use?
16:20:53 <mestery> vthapar: You mean collapse from br-int/br-tun/br-ex to a single bridge?
16:20:59 <rkukura> Like every other BP for juno, we’ll need to get an updated BP for ovs-firewall-driver through the spec review process
16:21:05 <asadoughi> vthapar: i haven't heard number of bridges being a constraint
16:21:12 <mestery> vthapar: I would be in favor of patches which moved the OVS agent in that direction.
16:21:25 <mestery> vthapar: OpenDaylight uses a single bridge, for example.
16:21:27 <asadoughi> rkukura: filed and approved during icehouse so i'd prefer to not resubmit
16:21:29 <vthapar> I was coming from a different direction, as in using multiple bridges based on functionality
16:21:51 <vthapar> I had discussed with asadoughi, using separate ovs bridge for security groups, say br-sec.
16:21:52 <banix> mestery: SDN-VE also uses a single bridge
16:21:53 <mestery> vthapar: Ah, interesting choice. So, isolate the features per-bridge?
16:21:54 <rkukura> mestery can clarify, but my understanding is all BPs for juno need to go through the new process
16:22:18 <vthapar> yes, I am working on a blueprint for the same, just need to do some prototyping and make sure it holds up.
16:22:21 <mestery> Yes, the way the new BP process works is that features which missed the previous release need to be re-approved for Juno now.
16:22:28 <mestery> vthapar: Very cool!
16:22:29 <asadoughi> mestery: ok
16:22:49 <mestery> asadoughi: If you have other questions around that, please let me know. This is a new process, so I'm happy to help.
16:22:58 <vthapar> think of it like a service chaining model, but for core neutron services.
16:23:00 <asadoughi> so should i stop coding and refile bp? can't do all things at once
16:23:24 <vthapar> asadoughi, I can help with bp.
16:23:28 <mestery> asadoughi: Hopefully you can simply migrate your existing BP over to the new neutron-specs repository with minimal effort.
16:23:47 <rkukura> mestery: I’m still not totally clear if we want the BPs in neutron-specs prior to the summit, if WIPs make sense for this, or if google docs are OK until the ideas get sociallized and teams formed at the summit
16:23:48 <mestery> asadoughi: Please keep coding, I expect your BP to not be too contentious since it was already approved for Icehouse.
16:24:10 <mestery> rkukura: I think we should be pushing specs to neutron-specs, and before the summit is perfectly fine.
16:24:16 <amotoki> mestery: who have responsibilities to review blueprints? nova team assigns two folks from nova-drivers to review BPs.
16:24:18 <mestery> rkukura: I don't think each BP needs a summit session.
16:24:33 <asadoughi> ok, i'll at least push a WIP by next week to neutron specs gerrit
16:24:35 <mestery> amotoki: Anyone can review them, neutron-cores can +2/+A the BPs.
16:24:46 <amotoki> okay.
16:24:58 <mestery> amotoki: For larger BPs, it may be good to assign neutron cores as reviewers of the resulting code as well. What do you think?
16:25:18 <amotoki> mestery: agree. it is a good idea.
16:25:19 <rkukura> getting some of these existing BPs through the process quickly would be a good way to get the ball rolling with the new process
16:25:36 <mestery> rkukura: +1 to that idea.
16:25:49 <mestery> I think asadoughi's BP is a good example of something we can approve quickly once it hits neutron-specs. :)
16:26:29 <rkukura> anythign else on ovs-firewall-driver before we move on to the design summit session ideas?
16:26:37 <asadoughi> nada from me.
16:26:43 <vthapar> I had question on using br-sec for SGs...
16:27:00 <vthapar> does it sound like a good idea or direction we want to be heading in? feature based bridges?
16:27:31 <banix> vthapar: what is the advantage of having such an architecture?
16:28:02 <vthapar> it provides isolation of flwos thsu making it easy to troubleshoot.
16:28:04 <amotoki> I think The advantage is that it makes easier to manage flow rules.
16:28:18 <rkukura> vthapar: And does traversing patch ports between bridges add overhead to the kernel datapath?
16:28:43 <vthapar> rkukura: that is the open question right, which I need to prototype and get test results of.
16:28:48 <vthapar> right now.
16:29:25 <vthapar> the sort of work I am doing, I am using a service VM which host these bridges, not on host OS.
16:29:39 <vthapar> so, it allows me possibility of providing a scaleout model.
16:30:12 <vthapar> e.g. if you have a few tenants but lots of SG rules, your SG flows maybe too high and will benefit from being separate instance.
16:30:48 <vthapar> another reason was that OVS2.0 only supports 2k flows in kernel space, I was avoiding that problem by having SG flows in separate bridge running in its own service VM, thus its own kernel.
16:30:49 <banix> so there will be for example a sec related bridge on each data path? meaning multiple such bridges if there are multiple network interfaces on a host?
16:30:54 <yamamoto> patch ports do not add overhead to the datapath afaik
16:31:15 <mestery> vthapar: I think the idea is worth exploring. Once you vet it a bit more, let us know how it looks.
16:31:16 <vthapar> not really, br-sec would need to sit where br-int sits today.
16:31:40 <vthapar> mestery: I Am working on BP, not published yet coz want to do some testing and get some concrete numbers.
16:32:12 <mestery> vthapar: Cool! It may be worth filing a summit session for this, or collapsing it into asadoughi's ovs-firewall session
16:32:15 <vthapar> the use case I have at my workspace kid of necessiates such an approach but I believe it will benefit all.
16:32:38 <rkukura> mestery: I was thinking the same thing
16:32:41 <amotoki> vthapar: br-sec sounds good to me for ovs-firewall-driver as we can separate a logic from the exsiting ovs-agent.
16:32:50 <vthapar> how should I go about it? file a bp first?
16:32:50 <mestery> amotoki: +1
16:33:01 <asadoughi> how long's a summit session anyway? ovs-firewall-driver might not even take up the full time as-is.
16:33:09 <mestery> vthapar: Yes, a BP is a good start, and then discussing as part of asadoughi's session in Atlanta woudl also be good!
16:33:15 <mestery> 40 minutes asadoughi
16:33:17 <rkukura> #topic Design summit session proposals
16:33:20 <mestery> So, combining them would be good
16:33:36 <vthapar> ok. will work on getting BP up before that so all get some context.
16:33:43 <rkukura> deadline for submitting proposals is Sunday, 4/20
16:33:46 <mestery> vthapar: Great!
16:33:52 <mestery> Yes, please file early!
16:33:56 <amotoki> asadoughi: if it does need full time, you can add a comment in session proposal.
16:34:00 <mestery> We're already over our allotted 20 spots.
16:34:09 <mestery> So we may converge a few sessions.
16:34:14 <amotoki> *if does *not* need
16:34:45 <asadoughi> ah, 40 minutes, i was thinking 1 hour.
16:34:48 <vthapar> 20 deadline might be bit difficult for me.
16:35:08 <rkukura> session proposals don’t need to be very detailed
16:35:10 <vthapar> am on vacation [sort of] with intermittent access.
16:35:22 <vthapar> aha, will do that.
16:35:27 <banix> vthapar: thats deadline for session proposals
16:35:41 <rkukura> We’ve been collecting ideas for session proposals to be filed at https://etherpad.openstack.org/p/juno_ml2_session_ideas
16:35:44 <vthapar> got it.
16:36:46 <rkukura> would be great if people that have filed proposals for ML2 could add link to proposal under “already filed ideas”, and move up any useful text from below
16:37:16 <Sukhdev> mestery, rkukura: Is there a limit on number of sessions for ML2 specific work?
16:37:25 <rkukura> Sukhdev and I will get the proposal on re-synchronization filed this week
16:37:55 <nlaouti> I have a question, is there  BP or work done on supporting mechanism driver RPC on the ovs neutron agent side
16:38:07 <rkukura> Lets discuss the dynamic VLAN stuff for a moment
16:38:09 <mestery> Sukhdev: No limit, other than practicial. If we can collapse ML2 sessions into 2 sessions, that might be ideal.
16:38:32 <amotoki> Is RPC stuff related to VLAN stuff? i am not sure.
16:38:39 <emaganap> mestery: +1 that is a good idea
16:39:05 <rkukura> I think that having the mechanism driver handle the get_device_details RPC will be needed for dynamic VLAN, at least on certain use cases
16:39:13 <amotoki> i see.
16:39:14 <Sukhdev> mestery: may be tight, but, we'll try :-)
16:39:17 <amotoki> I have an idea to refactor RPC callbacks in all neutron plugins. The current mixin apporach prevents each RPC API from evolving separately.
16:39:24 <nlaouti> Not really.
16:39:31 <amotoki> it is not directly related to ML2 but i can cover it.
16:39:46 <nlaouti> amotoki: in some cases MD may need to send info to ovs agent
16:40:08 <amotoki> nlaouti: yes. i understand the need.
16:40:19 <amotoki> some driever need to receive RPC too.
16:40:33 <rkukura> I’m thinking that the bound MD should be responsible for handling get_device_details, and maybe it should defer to the segment’s type driver in most cases
16:40:36 <nlaouti> amotoki: thats correct
16:41:00 <nlaouti> amotoki: l2_pop implemeted one which is being used by l2_pop
16:41:09 <asadoughi> banix: +1 for modular agent discussion. ovs_neutron_agent is bloating as-is.
16:41:10 <rkukura> Adding new RPCs in drivers is kind of related to having extensions supported by drivers, isn’t it?
16:41:55 <amotoki> it is sometimes related to having new extensions, but it is not always.
16:42:03 <nlaouti> rkukura: that could be one of the cases
16:42:33 <rkukura> So I plan to file a session proposal on just very basic changes to ML2 to allow the bound MD to dynamically assign VLAN tags
16:42:52 <nlaouti> rkukura: as part of my work on Mechanism driver, I needed to have RPC on ovs_agent for the MD.
16:43:21 <rkukura> I think separate session proposals for VDP and such make sense, and mestery can combine these into one session
16:43:52 <rkukura> nlaouti: Are you saying you need the MD to make and RPC call to the agent?
16:43:53 <nlaouti> rkukura: For now I create RPC  bases on some config option on ml2_conf.ini on ovs agent and on server side
16:44:08 <nlaouti> rkukura: yes
16:44:20 <banix> amotoki: is there a blueprint for your work on unifying  RPC callbacks
16:44:35 <amotoki> I will register it tomorrow.
16:45:00 <amotoki> I don't think it need a session proposal.
16:45:51 <rkukura> nlaouti, amotoki: Seems the extensibility of the REST and RPC interfaces could be covered together in one session, or maybe as part of the catch all session
16:46:21 <amotoki> rkukura: sounds good.
16:46:42 <nlaouti> rkukura: sounds good
16:46:53 <rkukura> Are there items on the etherpad (or not yet on it) that need volunteers to submit proposals?
16:47:18 <rkukura> Does anyone want to look into the bulk operations?
16:49:00 <rkukura> Any other session topics to discuss?
16:49:25 <amotoki> re bulk operation, it is very different between agent case and sdn controller case, so I could not cover both cases so far.
16:51:04 <rkukura> amotoki: Basic question I have on bulk operations is whether the ML2 plugin should handle them as separate operations, each with precommit followed by postcommit
16:51:18 <rkukura> of if all precommits should happen in one transaction
16:51:39 <rkukura> of it the drivers should have a bulk_precommit and bulk_postcommit method
16:51:49 <rkukura> s/of it/or if/
16:52:09 <Sukhdev> rkukura: Do you have a use case in mind?
16:52:48 <rkukura> Sukhdev: Not really, just want to make sure we aren’t calling controllers/devices from inside transactions
16:53:09 <amotoki> my initial thought is to commit all requests in one (bulk_)precommits and then bulk_postcommit. it seems easier to rollback.
16:53:19 <Sukhdev> rkukura: I can think of this being useful in the re-sync process
16:53:29 <amotoki> perhaps same as your thought.
16:53:40 <rkukura> Sukhdev: interesting
16:54:15 <rkukura> Do we need anything related completing the deprecation of the monolithic plugins?
16:55:09 <asadoughi> monolothic plugins maybe not, but monolithic agents.. i'm curious in general how we would go about refactoring (e.g. RPC, agent) when there are active feature implementations ongoing; obviously with nova-network parity being a priority, that will make it more difficult.
16:55:10 <rkukura> We’ve got a migration tool now, and I guess we’ll be removing code in juno, and maybe moving the L2 agents (or refactoring them as drivers in a modular agent)
16:56:39 <mestery> asadoughi: That's a good point. nova-network parity is priority #1 for Juno, so we can't slow that down at all. :)
16:57:07 <rkukura> #topic Open Discussion
16:57:17 <rkukura> We’ve got a couple minutes left - anything else?
16:57:28 <asadoughi> mestery: yeah, and nova-parity patches are making agent more monolothic!
16:58:25 <asadoughi> banix: thoughts?
16:58:27 <banix> asadoughi: do you have any particular patch in mind or in general?
16:58:29 <amotoki> Do we use ML2 with OVS or ML2 with linuxbridge for nova-parity? It may be one topic in the summit. OVS with hybrid have a performance issue.
16:59:29 <asadoughi> banix: is https://review.openstack.org/#/c/87730/ nova-parity or related, i think saw something about distributed dhcp in the dvr meeting prior adding on to this
16:59:47 <mestery> amotoki: Maybe I should file a summit session on deprecation plans for LB and OVS, and we can cover that there.
16:59:51 <mestery> Not sure if needs a full session or not.
16:59:56 <mestery> Maybe in a broader "juno plans" session
16:59:57 <rkukura> amotoki: Hopefully the ovs-firewall-driver will eliminate the hybrid bridge
16:59:59 <asadoughi> amotoki: everyone could switch ovs non-hybrid if ovs-firewall-driver is implemented? :)
17:00:25 <vthapar> is firewall driver only reason for using linux-bridge today?
17:00:30 <rkukura> we are out of time
17:00:31 <rkukura> OK, lets get the summit session proposals in, and start working on writing and reviewing BPs!
17:00:35 <amotoki> mestery: sounds good. we need to clarify all nova-parity plans.
17:00:36 <banix> asadoughi: thanks will look into this patch in partiular and this issue in general
17:00:38 <rkukura> #endmeeting