zlacker

I really tried to make wsl work for the windows users on my team, but we kept getting tangled up with networking (I guess there's a virtual switch involved and so when a tool claims to have forwarded a port it's hard to figure out where it forwarded it to and why only half of your stuff can see it).

Do you know if that situation has improved in the last year or so?

>>__Matr+(OP)
I'd like to know on your use case more, if possible. Not sure I've ever need to forward port or I probably read your description wrong way.

>>CoolCo+m5
It's been a year but if I recall it went something like this:

I was using microk8s (a kubernetes distribution) on the wsl side, and I had python scripts (also on the wsl side) which would deploy things into it, run tests until there was a problem, forward a port from the broken service to "localhost:8080", and then instruct the user to open a browser to explore the UI post-test-failure.

On bare metal Linux this was no big deal because "localhost" was unambiguous. But on windows you end up with the browser on the windows side and the forwarded port on the wsl side, so when the browser opened there was nothing at "localhost:8080" even though I could "curl localhost:8080" from the wsl side and get a response.

Presumably there is a way to further forward the port so that it is available to both Windows browsers and wsl python scripts, but I never found it.

>>__Matr+(OP)
We got stuck on the Nvidia opencl drivers before we went deep into k8s networking

Our experience with local k8s dev is the issues are more on the k8s distro side. So at least for local dev, I'm guessing the happier path is sticking with KinD approaches wrt WSL2. Our wsl2 docker testing was successful, even w GPUs, and bc of the file system seperation, felt more like native Ubuntu docker's imperceptible overheads vs the painfully slow OS X docker overheads (ex: npm run watch taking minutes vs seconds)