Chaudhry (CC'd ovsdb and integration dev),
I've spent some time debugging your troubles [0] in the sandbox. It
looks
like the trouble is coming from something being done in either of
your
vxlan test suites. As soon as one of those suites is run, it's no
longer possible to ssh in to the mininet VMs.
You can toggle the order in which suites are run [1] (search for
pybot) to
verify this if you want, but I wonder if you run this in your local
environment
you might also have trouble. Running a single vxlan suite seems to
be
fine, but running any other suite after it fails. even running the
same
vxlan suite back to back will see the first one PASS and the second
one
FAIL.
Let me know if you can see this in your own environment, and if not
we'll
have to keep digging in the sandbox to find the root cause.
The final few steps of the vlxan suite are to:
- stop mininet (requires logging in to VM and that works)
- sending a DELETE to:
/restconf/config/network-topology:network-topology/topology/ovsdb:1/node/ovsdb:%2F%2F${MININET}:6634
(that gives a 200 response)
then the next suite runs and it's first attempt to log in to the
${MININET} system
fails. Could there be some networking issue on the linux level that
gets
triggered by playing with vxlan and then deleting the node from
restconf?
(thinking out loud)
Let me know what you figure out and I'll see what I can do to help
after that.
Thanks,
JamO
[0]
https://jenkins.opendaylight.org/releng/job/ovsdb-csit-verify-southbound-master/116/
[1]
https://jenkins.opendaylight.org/sandbox/job/ovsdb-csit-1node-cds-southbound-all-master/configure