Yep, I know :) And as I said, I like your solution as far as it goes :) Ed On Dec 2, 2013, at 9:47 PM, Madhu Venugopal <mvenugop@...> wrote:

Anees, I don’t much like the notion of turning one and only one participant off by default in an Edition. Its possible we have to fall back to starting all off and having the user decide which to

Lori, my understanding of the the multi-segment support in ML2 is different -- I would say its intent is to allow OpenStack to work over multiple network types at the same time, not to force the

So from what I understand from this and other previous conversations, it looks like there are 2 trends for the Virtualization edition: 1) Run all apps together but try to use only one

Ok, I'll schedule a meeting to decide resolution for next release.

Hi Suchi, Good questions. I will not pretend to be an expert in this area as I have had little time to dig into these projects unfortunately. My reaction/response is therefore one of practicality.

In addition to the basic metadata setting/getting, the affinity engine has a way to set forwarding rules for traffic redirection. This is the feature required for Radware. We have a couple of options

Anees, I would say OpenStack already is somewhat aware of the details of the virtualization implementation, since you get to choose between VLAN, GRE, and VXLAN tunneling. So I agree with Madhu that

Madhu, I don't think this is the right way to handle this -- IMO Neutron shouldn't need to be aware of details of the virtualization implementation. In keeping with the notion of Neutron being

As we've discussed at some length, Affinity is not in the same category of function as the virtualization implementations, and also doesn't implement the Neutron APIs, so I don't think the issue of

Hey all, I'm documenting the steps I'm doing to get ML2/ODL working (mostly for myself), but maybe some bits will be useful to someone, so I thought I share it. I know there are better tutorials out

Hi Ed, Madhu’s proposal focus on the co-existing problem between southbound drivers for Neutron Interface. I explained about this problem in the following

As explained in today's call, I started this discussion with neutron in mind. I have to understand the problem with affinity before I can expand this discussion beyond neutron. I think Suchi is

So I see the value of this... But what about Affinity? Ed On Dec 2, 2013, at 7:57 PM, "Hideyuki Tai" <h-tai@...> wrote:

Hi Madhu, I completely agree with your opinion. Regards, Hideyuki Tai

Team, Upgraded my testbed to use OVS2.0 which supports VXLAN forwarding (OVS1.11 didn't work for me. Not sure why). With this upgrade and a few stability fixes, Unicast P2P VXLAN overlay (as

Hi Kyle, OpenDove, VTN & OVSDB devs, Since we all have integrations completed with the Neutron nb-apis and these southbound drivers (ovsdb, open-dove, vtn) cannot co-exist in the same

Guys, Our Maven declarations need a lot of work. I have been busy with getting the ovsdb / neutron functionalities integrated and had postponed this work for sometime. Will

Hi Thanks for your reply. By changing pom.xml in ovsdb/neutron, ovsdb.neutron build successfully, and my java version 1.7.0_07. 2013/11/28 alagalah <alagalah@...>

Hi Huang, I just did a pull and I don't have this issue. Not sure if we need to edit the pom but I see your point. Did altering the POM get you