For External connectivity beyond the network gateway, rather than pinging google.com, configuring the vm for an external DNS server and pinging it by IPaddress would be a good initial test of external connectivity.
--Rocky From: Tomoe Sugihara [mailto:to...@midokura.com] Sent: Tuesday, November 19, 2013 7:31 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Rami Vaknin Subject: Re: [openstack-dev] [Openstack][qa][Tempest][Network] Test for external connectivity Hi Salvatore, et al, On Mon, Nov 18, 2013 at 9:19 PM, Salvatore Orlando <sorla...@nicira.com<mailto:sorla...@nicira.com>> wrote: Hi Yair, I had in mind of doing something similar. I also registered a tempest blueprint for it. 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. 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) 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 www.google.com<http://www.google.com> 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. Two more things to consider on external network connectivity tests: 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 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. 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. So, I have some questions: - 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)? - For external connectivity, how can we test connectivity without floating ip? - should we have another vm and control that from the access VM e.g. by ssh remote command? or - 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? Thanks, Tomoe Regards, Salvatore On 18 November 2013 13:13, Giulio Fidente <gfide...@redhat.com<mailto:gfide...@redhat.com>> wrote: On 11/18/2013 11:41 AM, Yair Fried wrote: I'm editing tempest/scenario/test_network_basic_ops.py for external connectivity as the TODO listed in its docstring. the test cases are for pinging against external ip and url to test connectivity and dns respectivly. since default deployement (devstack gate) doesn't have external connectivity I was thinking on one or all of the following I think it's a nice thing to have! 2. add fields in tempest.conf for * external connectivity = False/True * external ip to test against (ie 8.8.8.8) I like this option. One can easily disable it entirely OR pick a "more relevant" ip address if needed. Seems to me it would give the greatest flexibility. -- Giulio Fidente GPG KEY: 08D733BA | IRC: giulivo _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
