<div dir="ltr">Hi Yair,<div><br></div><div>I had in mind of doing something similar. I also registered a tempest blueprint for it.</div><div>Basically I think we can assume test machines have access to the Internet, but the devstack deployment might not be able to route packets from VMs to the Internet.</div>
<div><br></div><div>Being able to ping the external network gateway, which by default is 172.24.4.225 is a valuable connectivity test IMHO (and that's your #1 item)</div><div>For items #2 and #3 I'm not sure of your intentions; precisely so far I'm not sure if we're adding any coverage to Neutron. I assume you want to check servers such as <a href="http://www.google.com">www.google.com</a> are reachable, but the routing from the external_gateway_ip to the final destination is beyond's Neutron control. DNS resolution might be interesting, but however I think resolution of external names is too beyond Neutron's control.</div>
<div><br></div><div>Two more things to consider on external network connectivity tests:</div><div>1) SNAT can be enabled or not. In this case we need a test that can tell us the SRC IP of the host connecting to the public external gateway, because I think that if SNAT kicks in, it should be an IP on the ext network, otherwise it should be an IP on the internal network. In this case we can use netcat to this aim, emulating a web server and use verbose output to print the source IP</div>
<div>2) When the connection happens from a port associated with a floating IP it is important that the SNAT happens with the floating IP address, and not with the default SNAT address. This is actually a test which would have avoided us a regression in the havana release cycle.</div>
<div><br></div><div>Regards,</div><div>Salvatore</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 November 2013 13:13, Giulio Fidente <span dir="ltr"><<a href="mailto:gfidente@redhat.com" target="_blank">gfidente@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/18/2013 11:41 AM, Yair Fried wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm editing tempest/scenario/test_network_<u></u>basic_ops.py for external<br>
connectivity as the TODO listed in its docstring.<br>
<br>
the test cases are for pinging against external ip and url to test<br>
connectivity and dns respectivly.<br>
since default deployement (devstack gate) doesn't have external<br>
connectivity I was thinking on one or all of the following<br>
</blockquote>
<br></div>
I think it's a nice thing to have!<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 2. add fields in tempest.conf for<br>
      * external connectivity = False/True<br>
      * external ip to test against (ie 8.8.8.8)<br>
</blockquote>
<br>
I like this option.<br>
<br>
One can easily disable it entirely OR pick a "more relevant" ip address if needed. Seems to me it would give the greatest flexibility.<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Giulio Fidente<br>
GPG KEY: 08D733BA | IRC: giulivo<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</font></span></blockquote></div><br></div>