Operating System: All
Platform: All

This happens using Boron 0.5.1-20161017.001225-477

Attachment compute1.txt has been added with description: Compute 1 (working) flows, ovs show

Attachment compute2.txt has been added with description: Compute 2 (not working) ovs show, flows

Attachment controller.txt has been added with description: Controller ovs show, flows, groups

Attachment karaf.log has been added with description: Karaf log

This is either a problem on the opnfv side or a misunderstanding of mine about some things. Either way, I'd like to mark is as INVALID but can't

Disregard the previous comment, I'll add more logs from a deployment with SR1, one OpenStack controller and two computes

Attachment karaf_logaa has been added with description: Karaf log with genius set to trace, 2nd set of logs, 1/3

Attachment karaf_logab has been added with description: Karaf log 2/3

Attachment karaf_logac has been added with description: Karaf log 3/3

Attachment ovs_logs has been added with description: ovs-vsctl show for controller and computes

Attachment itm-transport-zones_after.xml has been added with description: restconf/config/itm:transport-zones before modifying environment

Attachment itm-transport-zones_before.xml has been added with description: restconf/config/itm:transport-zones after modifying environment

https://gerrit.opnfv.org/gerrit/#/c/23971/3/test/functest/testcase_6.py
This is what was being run when the DHCP failures occurred. Instances 'sdnvpn-6-5' and 'sdnvpn-6-3' failed to get an IP.

This happens with odl-netvirt-openstack, I am not using the old vpnservice features.

It seems this bug stems from the usage of the same TEP in multiple Genius' ITM transport zones.
According to Genius this is a missing functionality and will be corrected to support all use cases.

Hema G will update accordingly.

Attachment autotunnels.zip has been added with description: Tunnels not created

Issue is with dpnendpoints. http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints

It assumes DPN is member of single TZ so unable to create mesh if a DPN ends up memeber of multiple TZs. transport-zone field in dpn-endpoints should be a list and should form mesh with all tunnels in all those transportzones.

(In reply to Vishal Thapar from comment #18)
> Issue is with dpnendpoints.
> http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints
>
> It assumes DPN is member of single TZ so unable to create mesh if a DPN ends
> up memeber of multiple TZs. transport-zone field in dpn-endpoints should be
> a list and should form mesh with all tunnels in all those transportzones.

What are our thoughts on fixing this by SR2?
Would it be possible to fix in Genius by that timeline?

The alternative seems to be avoiding multiple TEP in TZ usage.
netvirt can be modified to always use the same TZ when add TEPs, which would kill the minimized mesh optimization but should keep automatic tunnels possible without hitting the Genius bug.

Please keep us posted, it is preferable to fix in Genius and maintain current netvirt behavior if possible.

(In reply to Alon Kochba from comment #19)
> (In reply to Vishal Thapar from comment #18)
> > Issue is with dpnendpoints.
> > http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints
> >
> > It assumes DPN is member of single TZ so unable to create mesh if a DPN ends
> > up memeber of multiple TZs. transport-zone field in dpn-endpoints should be
> > a list and should form mesh with all tunnels in all those transportzones.
>
> What are our thoughts on fixing this by SR2?
> Would it be possible to fix in Genius by that timeline?
>
> The alternative seems to be avoiding multiple TEP in TZ usage.
> netvirt can be modified to always use the same TZ when add TEPs, which would
> kill the minimized mesh optimization but should keep automatic tunnels
> possible without hitting the Genius bug.
>
> Please keep us posted, it is preferable to fix in Genius and maintain
> current netvirt behavior if possible.

Yep, plan is to fix by SR2 timeframe. Hema is working on a fix though it is bit tricky. However, I ended up coming up with a patch when trying to test my OFTunnel changes.

https://git.opendaylight.org/gerrit/48716

It is not done [haven't touched deletion code at all] but add code works and seems to be enough to fix the issue. If you can test this patch and confirm/deny it fixes the create part, then we can at least try and get this in for SR2.

(In reply to Vishal Thapar from comment #20)
> (In reply to Alon Kochba from comment #19)
> > (In reply to Vishal Thapar from comment #18)
> > > Issue is with dpnendpoints.
> > > http://10.0.43.238:8181/restconf/config/itm-state:dpn-endpoints
> > >
> > > It assumes DPN is member of single TZ so unable to create mesh if a DPN ends
> > > up memeber of multiple TZs. transport-zone field in dpn-endpoints should be
> > > a list and should form mesh with all tunnels in all those transportzones.
> >
> > What are our thoughts on fixing this by SR2?
> > Would it be possible to fix in Genius by that timeline?
> >
> > The alternative seems to be avoiding multiple TEP in TZ usage.
> > netvirt can be modified to always use the same TZ when add TEPs, which would
> > kill the minimized mesh optimization but should keep automatic tunnels
> > possible without hitting the Genius bug.
> >
> > Please keep us posted, it is preferable to fix in Genius and maintain
> > current netvirt behavior if possible.
>
> Yep, plan is to fix by SR2 timeframe. Hema is working on a fix though it is
> bit tricky. However, I ended up coming up with a patch when trying to test
> my OFTunnel changes.
>
> https://git.opendaylight.org/gerrit/48716
>
> It is not done [haven't touched deletion code at all] but add code works and
> seems to be enough to fix the issue. If you can test this patch and
> confirm/deny it fixes the create part, then we can at least try and get this
> in for SR2.

Thanks a lot for this Vishal.
Confirmed that this fixes the issue, added a comment to the gerrit.

First patch fixing add use cases:

Master: https://git.opendaylight.org/gerrit/48716
stable/boron: https://git.opendaylight.org/gerrit/#/c/48817/

Closing, as this bug was resolved.

Deletion of TEPs will be implemented in https://git.opendaylight.org/gerrit/#/c/48952 and usage of it by netvirt should be done in https://bugs.opendaylight.org/show_bug.cgi?id=6560