16:00:08 <mestery> #startmeeting networking_ml2
16:00:09 <openstack> Meeting started Wed Apr  9 16:00:08 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:09 <kevinbenton> hi
16:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:12 <otherwiseguy> hi
16:00:13 <openstack> The meeting name has been set to 'networking_ml2'
16:00:30 <mestery> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_April_9.2C_2014 Agenda
16:01:00 <mestery> rcurran: Is asomya around? I emailed him about presenting his TypeDriver work but got no response.
16:01:22 <rcurran> no. family issue.
16:01:29 <mestery> rcuraan: OK, got it, thanks.
16:01:51 <mestery> So, I'd like to spend some time on Juno Design Summit items today, but first I'd like asadoughi to spend some time on his OVS firewall driver
16:01:56 <mestery> #topic OVS Firewall Driver Update
16:01:58 <Sukhdev> hi
16:02:04 <mestery> asadoughi: hi
16:02:06 <asadoughi> hi
16:02:37 <asadoughi> yes, so re-opened the bp and targeted for juno-1 now that ovs 2.1.0 is available and juno is open for development
16:02:49 <asadoughi> short term goal is to restore all 4 existing patches over the next week
16:03:05 <mestery> asadoughi: Great! I've seen those reviews become active lately.
16:03:14 <asadoughi> long term goal is to have working stateless implementation uploaded to gerrit by summit, (5 weeks)
16:03:56 <banix> asadoughi: long term == 5 weeks :)
16:04:12 <asadoughi> i had some off-list discussions with vthapar; vthapar will be looking into reflexive learning (stateful) now that ovs data path flow limit is over 200K flows; ultimately, thinking about providing a parallel implementation so the user can decide which driver style will meet their performance constraints (statless vs stateful)
16:04:35 <asadoughi> that is all. questions?
16:04:38 <mestery> asadoughi: Very cool!
16:04:48 <mestery> asadoughi: Do you happen to have the BP link handy?
16:04:57 <asadoughi> blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver
16:05:23 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver OVS Firewall Driver BP
16:05:57 <mestery> So do you think you'll have both stateless and stateful firewall support ready in 5 weeks?
16:06:25 <asadoughi> i doubt it
16:06:34 <mestery> :)
16:07:05 <mestery> I recall your email thread on ovs-discuss, and Justin indicated they were integrating linux connection tracking. Any update on that by chance?
16:07:28 <asadoughi> no update on that front
16:07:42 <mestery> OK.
16:07:44 <asadoughi> vthapar: you just missed my mention of our previous discussion
16:07:47 <mestery> Any other questions for asadoughi around this?
16:08:10 <asadoughi> i'll send another email on the ovs list
16:09:07 <vthapar> I hope to get some results of flow testing with OVS2.1 by next week.
16:09:14 <mestery> vthapar: Cool!
16:09:19 <mestery> asadoughi: Thanks for the update!
16:09:34 <mestery> #topic Juno Design Summit
16:09:42 <mestery> #link https://etherpad.openstack.org/p/juno_ml2_session_ideas Juno Design Summit Etherpad
16:09:51 <mestery> I created the above etherpad to track ML2 ideas for the Summit
16:09:57 <mestery> I see people have been adding ideas there, thanks!
16:10:46 <mestery> banix: I just noticed your idea at the bottom (base mechanism driver for controllers)
16:10:51 <mestery> To be honest, I think that may make sense.
16:11:00 <mestery> The Tail-F driver and the ODL driver are somewhat similar for example.
16:11:17 <nlahouti> I also added ML2 MD support for extensions
16:11:42 <banix> mestery: ok; how do we go about doing this or discussing more?
16:12:17 <mestery> banix: I would file a Summit Session for this and we can work it into the agenda.
16:12:30 <banix> mestery: sounds good. thanks.
16:12:43 <mestery> nlahouti: Thanks for that! I think that is something we've toyed with for a while now, so trying to resolve that will be good.
16:13:32 <rkukura> I listed some ideas I’ve been thinking about for a while
16:13:33 <nlahouti> mestery: I added more details of changes in summit session link
16:14:28 <mestery> nlahouti: Thanks!
16:14:36 <mestery> rkukura: Thanks for adding all of your info there as well.
16:14:38 <rkukura> I suspect some of the ones I listed overlap with others
16:14:54 <nlahouti> Also we need some changes related to VDP support in OVS and if it is okay can we discuss it here ?
16:14:59 <mestery> rkukura: Does it make sense to try to merge some ML2 items into a "super-session" again like we did in Hong Kong, giving people 10-15 minutes each?
16:15:05 <banix> nlahouti, mestery: Yeah I think we have to add this support sooner or later
16:15:09 <Sukhdev> I like some of the ideas and have interest in them - do folks have worked out any details  on these?
16:15:13 <rkukura> mestery: I think so
16:15:20 <mestery> nlahouti: OVS changes are not in the domain of OpenStack. Do you mean actually changes to OVS itself?
16:15:27 <rkukura> We don’t need entire sessions for ideas that are already well understood
16:15:35 <mestery> rkukura: Agreed.
16:15:56 <nlahouti> mestery: I meant OVS neutron agent
16:15:57 <mestery> We should converge on what Juno items we want to work on and try to get them staffed with people by the Summit or soon after.
16:16:47 <mestery> nlahouti: OK, then that is applicable here. Is that added to your BP yet? Or do you want to give us a quick summary here?
16:17:26 <nlahouti> mestery: it is added to https://blueprints.launchpad.net/neutron/+spec/netron-ml2-mechnism-driver-for-cisco-dfa-support
16:18:10 <mestery> nlahouti: OK, thanks!
16:18:19 <rkukura> nlahouti: Does DFA overlap with my “dynamic VLAN segment type for ToR switch” idea?
16:18:25 <padkrish> mestery: even though it's added under cisco-dfa mechanism driver, it can be used in general for anyone needing VDP support
16:18:39 <rkukura> what does VDP expand to?
16:18:46 <mestery> padkrish: It may make sense to split that out into it's own BP so it can be merged separately then.
16:19:04 <nlahouti> rkukura: I haven't read it yet It could be.
16:19:41 <padkrish> rkukura: It stands for VSI discovery protocol and it's a part of QBG IEEE standard
16:19:44 <Sukhdev> rkukura, nlahouti: It does have similarities -
16:19:59 <padkrish> mestery: Ok
16:20:22 <mestery> Agreed on the similarities
16:20:33 <nlahouti> sukhdev: is there any BP for that?
16:20:38 <Sukhdev> nlahouti: you should look into asoumya work as well - there is similarity there as well
16:21:27 <Sukhdev> nlahouti: yes there is mestery provided link in last meeting - do not have handy now, but, can look
16:21:37 <padkrish> sukhdev: Yes, we discussed with asomya, from what i understood from him, it's different
16:21:40 <mestery> rkukura: I think the "dynamic VLAN segment type for ToR switch" idea is going to be something we should do early in Juno, as it will help a lot of these things out.
16:22:10 <Sukhdev> mestery: +1
16:22:52 <banix> Sukhdev: nlahouti: #link https://blueprints.launchpad.net/neutron/+spec/ml2-type-driver-refactor
16:23:19 <mestery> Thanks banix!
16:23:19 <nlahouti> banix: thx for the link
16:23:20 <rkukura> mestety: I could writeup a succint BP for it, but if something more aligned with QBG is needed, someone else may want to do it, or help
16:23:25 <Sukhdev> padkrish: In that case, perhaps you can highlight the differences ---- all of us do not want to be comming up with diffentent implementations of similar ideas
16:23:44 <nlahouti> we will look into it
16:24:05 <padkrish> sukhdev: Yes, i remember looking at this one. Here, they separate the segment allocation to the type driver
16:24:47 <padkrish> #sukhdev, mestery: In VDP, it's a protocol which sends the vNIC information to the ToR and the ToR sends the VLAN to be used for that VM.
16:25:27 <nlahouti> if there are differences should we have new BP and also wirte up for the desing summint sessison?
16:25:47 <padkrish> #sukhdev: VDP protocol runs in each of the compute nodes.
16:25:59 <mestery> It seems there is some overlap here for sure, we need to figure out how to ensure we make something extensible for all the use cases.
16:27:03 <rkukura> sounds like we may want a simple framework for this in ML2, where the openvswitch agent MD can use the dynamically assigned VLAN, but a separate driver of some work (maybe the type driver) allocates the VLAN, and this can have a simple neutron-DB-based implementation and one that uses the VDP standard.
16:27:06 <padkrish> mestery: The work by Arvind has this segment allocation pushed to type drivers. What i see is Type drivers run only in the controller.
16:27:08 <Sukhdev> mestery: I think I like rkukura's idea of putting together some generic VLAN solution (with some extensions) to cover most of these use cases
16:28:03 <mestery> padkrish: The similarities with what asomya is doing and VDP is that VLANs are per "host to ToR", if we can make that work we'll be good I think.
16:28:27 <banix> Sukhdev: makes sense
16:28:42 <Sukhdev> mestery: correct analysis
16:28:52 <rkukura> This definitely is sounding like a good session topic where there are a number of efforts or use cases that require similar support in ML2
16:29:41 <mestery> Agreed rkukura, I think we should definitely have a session on this.
16:29:44 <rkukura> But I think asomya’s BP covers a more specific topic, so should be a separate session
16:29:46 <padkrish> mestery: Yes, that part is same. But, my understanding of  asomya's work is, it's like top-down assignment where controller knows the assignment. VDP is more like bottom-up where compute nodes query the TOR for VLAN
16:29:46 <Sukhdev> rkukura: I have very strong interest in this as well
16:29:47 <mestery> Who wants to file this one?
16:30:21 <mestery> I can certainly do it.
16:30:33 <rkukura> I’ll file one that’s very generic about dynamic VLAN allocation. Others can do more specific proposals, and we can combine
16:31:02 <mestery> +1 to that rkukura
16:31:14 <Sukhdev> padkrish: my understanding of asoumya work is that it is a late binding model - hence, I wanted him to present, so that we can all understand
16:31:15 <padkrish> rkukura, mestery: Sure, i can give my inputs on the VDP side
16:31:32 <padkrish> Sukhdev: Sure
16:31:51 <Sukhdev> + to rkukura as well
16:32:20 <Sukhdev> rkukura; if you like I can help you with that
16:32:54 <rkukura> can we get asomya next on the agenda next week?
16:33:36 <mestery> rkukura: Yes, I'll work to make sure asomya is here.
16:34:00 <padkrish> rkukura: Sure, and then we can compare with VDP and its similarities and differences
16:34:53 <mestery> OK. any other Juno Summit ideas to discuss here?
16:35:20 <Sukhdev> mestery: we need to short list the ideas soon
16:35:39 <mestery> Sukhdev: Yes, as the filing deadline is April 20th.
16:36:09 <rkukura> anyone interested in putting together a session on bulk ops?
16:36:21 <rkukura> Or on modulat agent?
16:36:25 <Sukhdev> mestery: leaving the Dynamic VLAN idea, we can go through the reaminging list and see what makes sense
16:36:27 <rkukura> modular
16:36:39 <rkukura> or on ML2 testing?
16:36:50 <mestery> rkukura: modular agent has been around for a bit, that's a good one if someone is interested!
16:37:14 <rkukura> someone would need to put some thought into the design and plan
16:38:16 <Sukhdev> rkukura, mestery: need to understand a bit better as to what you are looking for - then I can see if I can spare some cycles (or join hands with someone)
16:38:27 <mestery> rkukura: Agreed, but with no less than 3 agents now (OVS, LB and OFAgent), it may make sense to collapse them.
16:38:51 <mestery> Sukhdev: We're talking about merging all 3 of the agents I mentioned ^^^
16:39:28 <irenab> there is also MellanoxAgent quite similar to others
16:39:50 <rkukura> beyond what mesteery just mentioned, drivers within in the agents for things like firewalls or QoS use some generic hooks
16:40:55 <irenab> I'll check if I can join hands on this topic
16:41:00 <mestery> irenab: Thanks, I forgot about that one!
16:41:16 <rkukura> irenab: right, support for specific SR-IOV cards, various kinds of offloading, etc., might be able to take advantage
16:41:51 <irenab> I also added point to the etherpad on flexible device naming, not tapXXX
16:42:20 <irenab> would be required by SR-IOV HW Switch agent
16:43:13 <mestery> OK, so it sounds like a modular agent is also a possible topic for Atlanta.
16:43:20 <mestery> There's enough interest here.
16:43:58 <Sukhdev> mestery: three topics and counting :-)
16:44:01 <rkukura> just need a driver for that one
16:44:04 <mestery> Sukhdev: :)
16:44:23 <mestery> rkukura: Agreed. Does anyone want to volunteer to drive the modular agent work? It will involve a fair amount of people since it touches 4 agents.
16:45:22 <mestery> If anyone wants to take that one, please reach out to me or rkukura.
16:45:25 <mestery> #topic Open Discussion
16:45:33 <kevinbenton> https://review.openstack.org/#/c/85592/
16:45:33 <mestery> Anything else this week or should we end a bit early?
16:45:45 <kevinbenton> how should i handle this error case
16:45:59 <kevinbenton> segment in DB with no network type driver
16:47:06 <mestery> kevinbenton: That's a good question. This is an end case issue. Did you see enikanorov's comments in the review?
16:47:43 <kevinbenton> yes, it scanning the whole db on startup an acceptable approach?
16:48:03 <kevinbenton> is*
16:48:03 <rkukura> kevinbenton: Maybe the delete should succeed, but the error logged.
16:48:23 <mestery> +1 to that rkukura
16:48:37 <rkukura> If the type driver doesn’t exist, reclaiming resources isn’t possible, but a DB admin could do that
16:48:42 <kevinbenton> rkukura: that’s what i was starting to think. if the network_type is gone it sort of implies that there is nothing to clean up
16:49:20 <rkukura> kevinbenton: right
16:49:39 <kevinbenton> rkukura: so i’ll just log an error and return
16:51:14 <mestery> OK, thanks everyone for attending this week!
16:51:21 <mestery> We'll see you all next week, same time and channel.
16:51:22 <banix> bye
16:51:26 <mestery> Keep those Summit ideas flowing!
16:51:28 <mestery> #endmeeting