Open Stack

Hi Salvatore, et al,

On Mon, Nov 18, 2013 at 9:19 PM, Salvatore Orlando <sorlando at 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 <gfidente at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/28168fac/attachment.html>