<div dir="ltr">Hi Salvatore, et al,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 9:19 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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" target="_blank">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></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<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></blockquote><div><br></div><div><br></div><div><div><div>As far as I know from the code (I'm new to tempest and might be missing something), test_network_basic_ops launches a single VM with a floating IP associated and test is performed by accessing from the tempest host to the guest VM using floating ip.</div>
</div><div><br></div><div>So, I have some questions: </div><div><br></div><div>- How can we test the internal network connectivity (when the tenant networks are not accessible from the host, which I believe is the case for most of the plugins)? </div>
</div><div><br></div><div>- For external connectivity, how can we test connectivity without floating ip?</div><div> - should we have another vm and control that from the access VM e.g. by ssh remote command? or</div><div>
- spawn specific VMs which sends traffic upon boot (e.g. metadata server + userdata with cloud init installed VM, etc) to public and assert traffics on the tempest host side? </div><div><br></div><div>Thanks,</div><div>
Tomoe</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div></div><div>Regards,</div><div>Salvatore</div></div><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 11/18/2013 11:41 AM, Yair Fried wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><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>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>