<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 24, 2021 at 4:24 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Aug 24, 2021, at 11:21 AM, Goutham Pacha Ravi wrote:<br>
> Hi,<br>
> <br>
> Bubbling up this issue - I reported a launchpad bug with some more <br>
> debug information: <br>
> <a href="https://bugs.launchpad.net/bugs/1939627" rel="noreferrer" target="_blank">https://bugs.launchpad.net/bugs/1939627</a><br>
> <br>
> I’m confused how/why only the Manila gates are hitting this issue. If <br>
> you’re reading - do you have any tests elsewhere that setup a nova <br>
> instance on a devstack and ping/communicate with the internet/outside <br>
> world? If yes, I’d love to compare configuration with your setup.<br>
<br>
It has been a while since I looked at this stuff and the OVN switch may have changed it, but we have historically intentionally avoided external connectivity for the nested devstack cloud in upstream CI. Instead we expect the test jobs to be self contained. On multinode jobs we set up an entire L2 network with very simple L3 routing that is independent of the host system networking with vxlan. This allows tempest to talk to the test instances on the nested cloud. But those nested cloud instances cannot get off the instance. This is important because it helps keep things like dhcp requests from leaking out into the world. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Even if you configured floating IPs on the inner instances those IPs wouldn't be routable to the host instance in the clouds that we host jobs in. To make this work without a bunch of support from the hosting environment you would need to NAT between the host instances IP and inner nested devstack instances so that traffic exiting the test instances had a path to the outside world that can receive the return traffic.<br></blockquote><div><br></div><div>Thanks Clark; the tests we're running are either outside CI - i.e., with local devstack, or on third party CI systems where the guest VMs would need to access storage that's external to the devstack. These are tempest tests that have no reason to reach out to the external world. I didn't know the reason behind this design, so this insight is useful to me! </div><br class="gmail-Apple-interchange-newline"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In <a href="https://bugs.launchpad.net/bugs/1939627" rel="noreferrer" target="_blank">https://bugs.launchpad.net/bugs/1939627</a> you are creating an external network and floating IPs but once that traffic leaves the host system there must be a return path for any responses, and I suspect that is what is missing? It is odd that this would coincide with the OVN change. Maybe IP ranges were updated with the OVN change and any hosting support that enabled routing of those IPs is no longer valid as a result? </blockquote><div><br></div><div>I was scratching my head and reading the OVN integration code as well - but neutron internals wasn't my strong suit. slaweq and ralonsoh were able to root-cause this to missing NAT rule/s in the devstack ovn-agent setup. \o/</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> Thank you so much for your help,<br>
> <br>
> Goutham<br>
> <br>
</blockquote></div></div>