search

containers / gvisor-tap-vsock

A new network stack based on gVisor
Apache License 2.0
269 stars 50 forks source link

Write tests to verify gvisor-tap-vsock works as it should #412

Open lstocchi opened 3 weeks ago

lstocchi commented 3 weeks ago

We should test if visor-tap-vsock works as expected. E.g. check if the ports are actually open, if the data sent and received are the same (from small to big data), ...

lstocchi commented 3 weeks ago

@evidolob @cfergeau feel free to add some other test ideas to verify it works fine. I still haven't looked deeply at the code so what I wrote came out from a discussion with @gbraad

cfergeau commented 2 weeks ago

What comes to mind:

https://github.com/containers/gvisor-tap-vsock/issues/321 is related. On each platform, we'd want to test enabling/disabling port forwarding from the API, check downloading/uploading, maybe between VM and host, and external data. checking for data corruption would be needed as well (ie run sha1/... on the downloaded/uploaded data). Maybe the DNS tests could be extended, but there are a few of these already. Detecting performance regressions would be nice, but this means we always run the same benchmark on the same machine, so it's less convenient to do on the long run.

evidolob commented 2 weeks ago

As for me is having ability to actual debug tests is crucial, not only the test itself, but gvproxy. It will make troubleshooting process mush easier.

cfergeau commented 2 weeks ago

See also https://github.com/containers/gvisor-tap-vsock/issues/357 and https://github.com/containers/gvisor-tap-vsock/issues/269

lstocchi commented 1 week ago

As for me is having ability to actual debug tests is crucial, not only the test itself, but gvproxy. It will make troubleshooting process mush easier.

Can you please rephrase it? I'm not sure I got it. What do you do to debug gvproxy atm? Asking as I never do that so trying to understand what are the difficulties and how to make it easier.