From: "Natarajan Dhiraviam" <Natarajan_Dhiraviam@...>
To: shague@..., ffernand@..., "Ravi Sabapathy" <Ravi_Sabapathy@...>
Cc: "Mohnish Anumala" <Mohnish_Anumala@...>, ovsdb-dev@...,
neutron-dev@..., "C Venkataraghavan" <C_Venkataraghavan@...>
Sent: Friday, July 10, 2015 9:42:54 AM
Subject: RE: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Sam, Flavio

Thanks for the inputs.
This allinone setup creates bridge, network & tenants.

We tried setting ODL_BOOT_WAIT to 300 and in one of two attempts br-int, OF
port connection was all fine.

We are trying to get this set-up consistent...

We wait for below logs, before issuing a ovs-vsctl set-manager. Hope these
are the ones to look for before doing a set-manager ?
Starting point is this
| INFO | Event Dispatcher | FeaturesServiceImpl | 20 -
| org.apache.karaf.features.core - 3.0.3 | Installing feature
| odl-ovsdb-openstack 1.2.0-SNAPSHOT
OVSDB socket is active
| INFO | entLoopGroup-7-1 | LoggingHandler | 106 -
| io.netty.common - 4.0.26.Final | [id: 0xc3b7928a,
| /0:0:0:0:0:0:0:0:6640] ACTIVE
OF socket is ready for listening
INFO | Thread-59 | TcpHandler | 256 -
org.opendaylight.openflowjava.openflow-protocol-impl - 0.6.0.SNAPSHOT |
Switch listener started and ready to accept incoming tcp/tls connections on
port: 6653

Start to OF socket ready is typically a little over 3 mins in our OS-ODL
setup (4GB RAM each in control/compute node) .
Regards
Natarajan

-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Thursday, July 09, 2015 10:33 PM
To: Sabapathy, Ravi
Cc: Dhiraviam, Natarajan; ffernand@...; Anumala, Mohnish;
ovsdb-dev@...; neutron-dev@...;
Venkataraghavan, C
Subject: Re: Openstack-ODL integration issues in stable/kilo + Lithium 0.3.0

Natarajan,

what all does the allinone setup do besides stack and start odl? Meaning does
it try to create any bridges or networks?

could you modify the allinone to add a 60s or 90s sleep in between when the
ovsdb node manager is set and when odl starts? Or switch from all in one to
external? I think what is happening is that odl is starting but it takes a
while to get to a resting state. netvirt is the last service to run since it
depends on neutron, openflowplugin and the southbound. Those can take a long
time to start and then when netvirt finally starts it can take another 30s
or so to start. So during that time if the stack is trying to connect to odl
there can be issues.

Thanks, Sam

----- Original Message -----

From: "Ravi Sabapathy"
To: "Natarajan Dhiraviam" , ffernand@..., shague@...,
"Mohnish Anumala"
, ovsdb-dev@...,
neutron-dev@...
Cc: "C Venkataraghavan"
Sent: Thursday, July 9, 2015 12:23:43 PM
Subject: RE: Openstack-ODL integration issues in stable/kilo + Lithium
0.3.0

++Venkat

From: Dhiraviam, Natarajan
Sent: Thursday, July 09, 2015 11:56 AM
To: Flavio Fernandes (ffernand@...); Sam
Hague; Anumala, Mohnish; ovsdb-dev@...;
neutron-dev@...
Cc: Sabapathy, Ravi
Subject: Openstack-ODL integration issues in stable/kilo + Lithium
0.3.0

Hi Flavio, Sam & All,


We were testing latest neutron/lithium odl / stable kilo devstack
combo in all-in-one mode few days back, using modified Flavio's
vagrant setup
(http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html)
we faced below issues(?).



1. on stacking - unstacking - stacking (with manager set appropriately),
br-int is *NOT* getting created consistently

2. Even times when br-int was successfully created, OpenFlow connection
to controller from ovswitch on control node is not setup consistently.

Anybody else faced similar issues ?



We created br-int / OF connection to ODL on port 6653 manually in above
cases and could see that the default pipelines flows are getting
programmed both on the control & compute node, however vxlan tunnel
weren't getting created and we programmed it manually in the ovs.
However ping from Tenant1-VM1 on control node to Tenant1-VM2 of
compute node fails. Compute node has received the broadcast ARP
request and sends it out to the Tenant1-VM2 as well. However the
tenant is not responding back to the ARP request. Unfortunately we
aren't able to dump / analyze packets on the Tenant1-VM2...



Tenant / VM definitions are WRT below diagram.

[cid:image001.jpg@...]


Regards
Natarajan & Ravi