Anees and Benny, No disagreements with earlier discussions. Affinity abstraction is a high level API that specifies the network path requirements (policy, connectivity, ...) for a set of endpoints.

Hideyuki Tai, I ran into a similar issue, and with Kyle's help, was able to fix it. In the repo Kyle mentioned, there's a file lib/nova. You want to add the following patch to that

Hi Thomas, Thank you very much for sharing this information! I’ll try the patch. Regards, Hideyuki Tai

Team, As most of you know already, we made significant progress on the Neutron integration and we will have the OF1.0 based GRE overlay support completed anytime now. All the corresponding code has

Hey guys, Do we have a document describing the call flow between Neutron and ODL? Would like to use that as a basis to put the same functionality in CloudStack. I’ve already got some of the

Hi Hugo, Since OpenDaylight has atleast 3 Neutron based south-bounds (OVSDB, OpenDove & VTN), we centralized the Neutron NB-API on the controller project. And each of the above 3 south-bound plugin

Ok. So it is pretty tightly coupled with the Neutron way of working right? So we don’t have generic apis yet that can be used by other orchestration platforms? Do we have some documentation online

Hi Hugo, The neutron NB APIs that you see here

Hi Hugo, Below are a couple of example Neutron API calls (GRE/VXLAN) that might help. I have the OVS logs also if that would help. We should have a Hangout and see how we can help with CLoudStack

Team, After couple of weeks of integration effort, we finally have a working Multi-node DevStack setup running Fedora 19 with Neutron ML2 opendaylight plugin integrated and working nicely using the

Thanks guys! Really appreciate all the help :-) So the flow from the CloudStack side is pretty much like this: 1. User creates a network Isolated guest network, meaning internal ip range dedicated

Hi Hugo, Thanks for the summary. This sounds a lot like today's Neutron integration. Neutron gives Network, Subnet and Port creates from Northbound. And OVS provides the libvirt triggered new VM-Port

Hi all Today, i follow https://wiki.opendaylight.org/view/OVSDB_Integration:Mininet_OVSDB_Tutorial section Clone the OVSDB Repo and Insert into Controller, to compile ovsdb neutron, but i

Hi all ovsdb northbound compiles failed too, error information is the following: steven@steven-Vostro-2420 ~/code/SDN/controller/opendaylight/ovsdb/northbound/ovsdb $ mvn clean install [INFO]

Hi all Step3, cd ../../ovsdbmvn clean install after i patched pom.xml as the following: diff --git a/ovsdb/pom.xml b/ovsdb/pom.xml index 02acec7..c3d01ae 100755 --- a/ovsdb/pom.xml +++

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

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@...>

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 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

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