16:02:20 <rkukura> #startmeeting networking_ml2
16:02:21 <openstack> Meeting started Wed Jul 29 16:02:20 2015 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:26 <openstack> The meeting name has been set to 'networking_ml2'
16:02:36 <rkukura> #topic Agenda
16:03:00 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_July_29.2C_2015
16:03:17 <rkukura> Is there anything anyone wants to add to the agenda today?
16:03:43 <rkukura> #topic Announcements
16:04:06 <rkukura> All I have is that liberty-2 is this week, and liberty-3 is the end of August
16:04:13 <rkukura> Any other anouncements?
16:04:48 <rkukura> #topic ML2 late-cycle plan
16:05:02 <rkukura> #link https://etherpad.openstack.org/p/Neutron_ML2_Mid-Cycle_Sprint
16:05:55 <rkukura> Thanks to everyone who has added their availability to the etherpad!
16:06:20 <rkukura> Looks like the best week to do this in San Jose would be 10/5 - 10/9
16:06:49 <rkukura> In yesterday’s neutron IRC meeting, there did seem to be some concern about too many mid-cycles, too much travel, …
16:06:53 * Sukhdev_ looking
16:08:04 <Sukhdev_> rkukura: also the later part of the week of 9/8
16:08:16 <rkukura> I’m looking at this sprint as an unofficial feature design/protyping sprint, since this is targetted at mitaka and there is no approved RFE/BP yet
16:09:02 <Sukhdev_> rkukura: I think 10/5 week is the best
16:09:04 <rkukura> Sukhdev_: That week could work, but for myself, and potentially anyone else traveling to the west coast, it would be more efficient to do this on a full week.
16:09:28 <Sukhdev_> rkukura: agree - lets go with 10/5
16:09:29 <rkukura> Is it too close to the Tokyo trip the end of that month?
16:10:42 <Sukhdev_> Or - if you prefer we can do it after summit - sometime in November/December - the code is going into Mitaka (did I say it right) anyway
16:11:19 <rkukura> I think this is most valuable if done before the summit, so we have something very concrete to socialize there
16:11:45 <Sukhdev_> rkukura: In that case 10/5 or later part of the week of 9/8
16:12:09 <rkukura> Lets go with 10/5, since nobody seems to have any issues with that week.
16:12:27 <Sukhdev_> sounds fine to me
16:12:49 <rkukura> I’d like to plan on at least 2 days with a 3rd optional if needed, so should we start Monday or Tuesday?
16:14:25 <Sukhdev_> I am OK any day of the week - the tradition for other mid-cycles is Wed - Fri :-)
16:14:26 <rkukura> We’ll figure out who is hosting and exactly which days, then send an email to openstack-dev inviting anyone interested in participating to attend.
16:14:45 <rkukura> Weds-Fri could work for me
16:15:32 <Sukhdev_> banix: you've been quite - come join us in SJ for this event
16:15:35 <rkukura> I have not seen any real discussion of other projects to include, so I’m thinking the focus will be on the async
16:16:30 <rkukura> banix: It would be great if you could, and we could try to arrange a hangout or webex if anyone wants to try to participate remotely.
16:16:39 <Sukhdev_> rkukura: asouma and shivharis keep saying they will be ready with physical topology discussion - but, I have not seen anything
16:16:47 <banix> Sukhdev_: hi; I am sorry I have been out for a few weeks busy dealing with other work
16:17:29 <rkukura> Sukhdev_: I don’t see asomya or shivharis here - we can put them on the agenda for next week
16:17:55 <rkukura> anything else on the mid/late/pre-cycle feature sprint?
16:17:55 <Sukhdev_> yes - agree
16:17:56 <banix> Sukhdev_: I won’t be able to join in person but will make every attempt to join remotely if that option available
16:18:11 <rkukura> banix: OK
16:18:38 <rkukura> #topic L2 Modular Agent discussion
16:20:46 <rkukura> This also relates to the next topic, the macvtap agent
16:21:06 <scheuran> ok, then this is the time for me to jump in
16:21:13 <scheuran> We're planning for a ml2 driver and agent to support macvtap guest attachments (independent from sriov)
16:21:29 <scheuran> The big question is, where such code should land...
16:21:32 <rkukura> scheuran: thanks
16:21:46 <scheuran> I was disucussing this today with sc68cal and we agreed to bring it up in this round again.
16:21:56 <scheuran> basically we have the following options
16:22:04 <scheuran> 1) own openstack repo networking-macvtap
16:22:11 <scheuran> 2) in neutron tree as new reference, own agent
16:22:20 <scheuran> 3) In neutron tree, Integrated into linuxbridge agent (reusing about 500 lines of code, mostly main loop, detecting new devices,...)
16:22:28 <scheuran> 4) modular l2 agent, but as long it is being discussed go with #1
16:22:35 <scheuran> 5) Prototyping modular layer 2 agent
16:22:48 <scheuran> I just wanted to gather some feedback what you think
16:23:13 <scheuran> integrating it into linuxbridge sounds promissing, as a lot of code could be reused
16:23:25 <scheuran> (main loop, mechanism of detecting devices,....)
16:23:28 <Sukhdev_> I like 5) from the long term point of view - what do you think banix?
16:23:53 <rkukura> scheuran: Long term, is there reason to have both linuxbridge and macvtap L2 agents?
16:24:14 <scheuran> yes
16:24:45 <scheuran> so there would be a config option to run the linuxbridge agent either in macvtap or in linuxbridge mode (default)
16:24:54 <scheuran> the reason for this is simply sharing code
16:24:58 <scheuran> nothing else
16:25:08 <rkukura> What is the reason for supporting both modes?
16:25:11 <sc68cal> scheuran: I don't think it needs to be a mode
16:25:17 <sc68cal> I'd rather see it as an interface driver
16:25:52 <rkukura> sc68cal: Do you mean an interface driver within a moduler L2 agent?
16:26:22 <sc68cal> rkukura: yeah - I have no proof to back things up but I think that's the easiest way to increase code re-use
16:26:42 <scheuran> yes, kind of an interface driver
16:26:54 <banix> what is an interface driver?
16:27:02 <scheuran> common would be the main loop and this detecting new devices and keeping its state mechanism
16:27:08 <rkukura> Could OVS be supported by an interface driver as well, or is it “more different”?
16:27:45 <scheuran> sc68cal, I guess an interface driver is nothing that does already exist, right?
16:28:01 <sc68cal> scheuran: the only thing we have that is sort of like it- is these classes https://github.com/openstack/neutron/blob/master/neutron/agent/linux/interface.py
16:28:07 <scheuran> sc68cal, It's just a "concept" that you're proposing
16:28:44 <sc68cal> scheuran: yes, currently it's just a concept
16:28:58 <rkukura> There are interface drivers for other agents such as DHCP, L3, and *aaS to plug their interfaces, but these are the other side of the interface than is being proposed here I think.
16:29:36 <sc68cal> rkukura: correct - the idea is take the parts of all the agents that is common, like the RPC loop and bookeeping, and split it away from the part that handles the actual network wiring
16:29:49 <rkukura> That link is the one I’m talking about being the “other side”
16:29:56 <sc68cal> rkukura: agreed
16:30:04 <rkukura> So similar pattern, but not that code
16:30:17 <sc68cal> rkukura: yes - exactly
16:31:02 <scheuran> So that would mean the linxubridge driver becomes a more generic driver
16:31:46 <scheuran> which also offers some plugin mechanisms to either support linxubridge or macvtap or some other in the future
16:31:49 <rkukura> Lets not confuse the two sides of the “interface” - one is for L3, DHCP, …, to plug into, the other is for the L2 agent to handle being plugged into.
16:32:46 <rkukura> I do think L3, DHCP, … should use a generic interface driver, similar to nova’s, that acts based on the binding:vif_type and binding:vif_details set by the bound mechanism driver.
16:33:06 <rkukura> But I don’t think that is relevant within the L2 agent itself.
16:33:49 <scheuran> maybe a more general question: Do you think such an integration (however it looks) like would be something to shoot for?
16:33:59 <rkukura> Is our goal to get to a single moduler L2 agent, with drivers for LB, OVS, macvtap, …?
16:34:09 <scheuran> or would a separate repo with a separate agent be an alternative?
16:34:27 <scheuran> in the macvtap case
16:35:12 <Sukhdev_> scheuran: separate repo gives you quick solution - and you are free to do what ever you want - but, I like option 5 for the long term point of view
16:35:21 <sc68cal> rkukura: My goal is to reduce the copy & paste I've seen in some of the agents - like the macvtap and the intel dpdk
16:35:32 <rkukura> If we have good reasons to support OVS, LB, and macvtap long term, I’d really prefer to see these as drivers within a modular L2 agent than see three separate agents duplicating code, possibly across different repos
16:35:35 <sc68cal> which are copy&pastes of the LB and OVS agent, respectively
16:35:49 <scheuran> Sukhdev_, but that could go hand in hand, right?
16:36:02 <Sukhdev_> scheuran: correct
16:36:36 <Sukhdev_> scheuran: banix was looking into the modular L2 agent - he would have great insight into this
16:36:53 <scheuran> just was wondering how evolved this concept already is...
16:37:45 <scheuran> or what's the reason for moving it out from release to release?
16:37:49 <scheuran> just priorities?
16:37:58 <scheuran> or design not finished?
16:37:59 <rkukura> When we started ML2, the concept wasn’t really very evolved - we just wanted to be able to plugin ToR drivers and reduce code duplication.
16:38:34 <rkukura> Until recently, we only had to L2 agents to worry about, now we are looking at 4 or 5, right?
16:38:42 <rkukura> s/to/two/
16:39:01 <scheuran> yes, that's true
16:39:57 <Sukhdev_> scheuran: for the reason rkukura mentioned, we have been looking into Modular L2 agent
16:40:18 <scheuran> I don't want to use all of your time for this discussion. Can we come to a direction in a few minute (does not need to be a decision)
16:40:33 <scheuran> or just sorting options that are a no-go?
16:40:35 <rkukura> So would option 5 be a way to get there during mitaka - implementing it for macvtap but designing it to be able to handle LB, OVS, … as well?
16:41:15 <Sukhdev_> rkukura: +1
16:41:34 <scheuran> rkukura, That could be the goal - if it works we'll see. It would at least be a prototype and help learning things
16:41:34 <sc68cal> I think that's probably the most productive way to go about it - at least when we start writing it we'll have a concrete consumer of it
16:41:49 <rkukura> scheuran: Are you targeting liberty or mitaka for macvtap?
16:42:13 <scheuran> rkukura, the goal is liberty
16:42:29 <scheuran> rkukura, (of course :)
16:42:59 <rkukura> OK, so could this be done in a way that would allow the others to be supported via drivers during mitaka?
16:43:34 <scheuran> rkukura, that would mean, that modular agent must be ready in liberty, right?
16:43:48 <rkukura> Then we could do a similar migration strategy to what we did with ML2 - ship both the modular an legacy L2 agents in mitaka, and remove the legacy ones in N
16:44:30 <Sukhdev_> and, that strategy worked well -
16:44:39 <Sukhdev_> I am sure we can make that work here as well
16:44:42 <scheuran> sure. Of course it depends on how advanced the concept of the ml2-agent is
16:45:12 <Sukhdev_> scheuran sc68cal: banix has done a lot of leg work on the modular L2 agent stuff - you may want to reach out to him.
16:45:24 <scheuran> Sukhdev_, sure, I will
16:45:30 <rkukura> scheuran: I’m suggesting calling it a modular agent, but only supporting macvtap initially (via a minimal driver interface that does what you need), and using this as the starting point for the mitaka modular agent work
16:46:03 <scheuran> rkukura, sounds good
16:46:19 <scheuran> Let me talk to banix and we can have a come back next week
16:46:28 <rkukura> scheuran: If that becomes the plan, I’d think putting the code in the same repo with ML2 would make most sense.
16:46:29 <banix> yeah looks like supporting the mactv driver could be the begining of the effort for modular agents
16:46:32 <banix> sure
16:46:44 <Sukhdev_> sounds like a solid plan
16:46:49 <scheuran> cause I have not yet an overview what it means implementing this agent...
16:47:21 <scheuran> rkukura, meaning neutron in tree?
16:47:51 <rkukura> scheuran: right, until the reference implementation stuff gets moved, and this would move with it
16:48:10 <scheuran> rkukura, alternative would be in a separate repo to get started quickly and then integrate it as soon it is matured
16:48:14 <sc68cal> I'd like to say I'm also doing a spike to see what parts of the OVS and LB agents overlap and see if I can get them to share code
16:48:18 <rkukura> either could work
16:48:41 <sc68cal> right now I'm just looking at the agent RPC layer for port and network updates
16:48:48 <sc68cal> no sgs
16:48:53 <rkukura> But ML2 benefited initially from having all the drivers in the same tree with the framework when it was evolving rapidly
16:49:30 <rkukura> So I think this would need to be in the same tree as ML2 before the work to intergate OVS and LB support began
16:49:31 <scheuran> rkukura, sure my concern was more about getting reviews and so on
16:49:38 <Sukhdev_> scheuran: starting with a separate repo with the intent to implement as a modular agent will be perfect goal - in fact, we can move other L2 agents to this repo as well -
16:50:18 <Sukhdev_> scheuran: we have been considering moving L2 agents out of neutron tree into separate repo - so, this may be great first step in that direction
16:50:29 <rkukura> Sukhdev_: Is there a concrete plan to move ML2 and the current agents to a different repo during liberty?
16:50:46 <rkukura> If so, starting this modular agent there would make sense if practical.
16:50:49 <scheuran> oh, will ml2 also move out?
16:50:58 <scheuran> I thought it was more about drivers and agents...
16:50:58 <Sukhdev_> rkukura: we discussed about this in the neutron mid-cycle in Fort Collins - but, did not really follow through
16:51:43 <rkukura> Sukhdev_: I’m not sure what the current plan is for moving ML2. Maybe its been decided that it stays with neutron.
16:52:02 <rkukura> we should move on
16:52:15 <scheuran> sure, thanks for your time!
16:52:29 <rkukura> scheuran: Can you put together a proposed plan for this?
16:52:42 <Sukhdev_> rkukura: there is no concrete plan about this - it was brought up for discussion - which means, there is a desire for it….however, this idea of having a separate repo for all L2 agents could be the first step in that direction
16:52:44 <scheuran> Sure. I'll come back to you next week
16:53:00 <rkukura> I don’t mean necessary for the full modular L2 agent effort, just to get your work unblocked with a view towards this
16:53:07 <rkukura> great - thanks!
16:53:15 <scheuran> rkukura, ok thanks!
16:53:49 <rkukura> we’ll skip physical topology since neither asomya nor shivharis is here
16:54:02 <rkukura> #topic Task Flow Document
16:54:11 <rkukura> #link https://docs.google.com/document/d/1aSgTVB7nW_v7lHH0Z0DUgfymEsx0O16k1Jgu7QFXkFA/edit?usp=sharing
16:54:48 <rkukura> Not sure we need to discuss this today, but want to get people working on this towards the 10/5 sprint we discussed earliuer
16:54:58 <rkukura> anything else on this?
16:55:15 <rkukura> #topic Open Discussion
16:55:57 <rkukura> Soneone added a couple patches to review in this section of the agenda - want to discuss these?
16:56:49 <Sukhdev_> I reviewed two of these - did not get a chance to get to the third one - it is basically clean up
16:57:55 <Sukhdev_> I got the email with the name of the person yesterday, but, not remembering the name now - sorry
17:00:21 <Sukhdev_> rkukura: time check -
17:00:23 <rkukura> Anything else today?
17:01:45 <rkukura> Thanks everyone!
17:01:47 <banix> bye
17:01:48 <rkukura> #endmeeting