Hi Salvatore, et al, On Mon, Nov 18, 2013 at 9:19 PM, Salvatore Orlando <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 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> 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 >> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev