Running tests on multiple remote cores using socket

[Alon-L]

I have a remote server, and I would like to run tests on its cores in parallel. This is simple enough using SSH, where I can pass n*ssh=.... For socket I would expect it would work with n*socket=.... However, the socketserver.py script linked in the execnet repo does not support parallel clients. So whenever I try to parallelize the socket argument using --tx 2*socket=... my master gets stuck after initializing one worker, since the socket blocks on the first connection.

Is there a better fix to this other than modifying socketserver.py to fork for every connection?

Thanks.

[RonnyPfannschmidt]

Socket server currently doesn't support multiple processes

The easiest way would be to add hop gateways to xdist and use popen//via=hop

In this case a hop gateway wouldn't run tests itself it would just proxy to multiple popen gates started via it

[Alon-L]

Socket server currently doesn't support multiple processes

The easiest way would be to add hop gateways to xdist and use popen//via=hop

In this case a hop gateway wouldn't run tests itself it would just proxy to multiple popen gates started via it

Thank you, this worked:

pytest -d --tx "socket=IP:PORT//id=my_proxy" --tx "5*popen//via=my_proxy"

However, it also treats the first tx argument as a remote worker, so I end up with 6 workers.
I looked at the xdist code for NodeManager. It seems that there's no way to call execnet's makegateway without registering the new gateway as a remote worker.

I'd like to create a PR to fix that, and I'm not sure which way to go for this. I'm currently thinking of adding an argument --xspec which is passed to the execnet's Group on initialization.
For example, my previous command becomes:

pytest -d --xspec "socket=IP:PORT//id=my_proxy" --tx "5*popen//via=my_proxy"

What do you think?

[RonnyPfannschmidt]

It needs a less generic name

[RonnyPfannschmidt]

Either a role=proxy on the tx or a arg name that explicitly names proxies

[Alon-L]

I thought this could be a more generic feature to control the xspec argument passed to Group on initialization, which can consequentially be used for proxies.
If you still think that's too generic, I think the role=proxy is a good idea. The only problem I see with it is that it's different than execnet's xspec specification. However, if you think that's fine then I'll add it.

[RonnyPfannschmidt]

Your explanation makes sense as well

For me the key is having non test gateway specs with a specific name

Using a role key would be supported by execnet already

However adding it with single use is potentially problematic