[discuss] Require WSL2 for development on Windows

[tylersmalley]

With Windows Subsystem for Linux (WSL2), it's pretty seamless to develop using Ubuntu on Windows. I have been doing this for over a year now. So, it brings up the question as to if we want to continue supporting Windows development.

This would have no effect on the Windows package, and we would continue to support it as a platform in production.

Some things which greatly assist with Windows development on WSL2:

• X410 to have a windows Gui for Chrome while running functional tests
  • Setting up Ubuntu (WSL) for Linux GUI Apps
  • Using X410 with WSL2
• Visual Studio Code - Remote Development plugin

Related to:

• Enforce source file path length limits #58054
• Optimize not being triggered when editing an SCSS file on Windows #56621
• Unable to start es on Windows using yarn es snapshot #49801
• Unit Tests fail shortly after Karma starts #47084
• Windows unit test failures jest tests #24284
• Windows unit test failures jest_integration tests  #24285
• Windows unit test failures on browser-ci  #24283
• Windows server unit test for proc runner is failing #24230
• [dev mode] Kibana regularly considers (wrongly) that all source files have changed and continuously restart #22859
• npm run test fails on Windows "EADDRNOTAVAIL 0.0.0.0:51126" #11407
• Kibana Optimizing and caching bundles for 28 hours #41726
• The changes in src/legacy are not watched #36013
• Can't setup development environment #27567
• Windows error on yarn kbn bootstrap  #26433
• Build task to check path length #25442
• Windows server unit tests for fs are failing  #23727
• "yarn es snapshot" fails on Windows 7 #20771
• "yarn es snapshot" fails on Windows #20063
• Setting up dev environment: Errors 800A0404 & 800A1391 #18701

@LeeDr & @peteharverson, have you used WSL2 or have any reasons for not using it?

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[joshdover]

This sounds like a great idea to me. Allows us to deprio tons of things that provide no value to our customers 👍

[LeeDr]

I've used WSL (Ubuntu) for some minor tasks but haven't switched over to it as my main development mode. I'd like to take some time next week and really try switching over, using my IDE, etc.

[LeeDr]

@tylersmalley can you run functional UI tests on your WSL? I installed google-chrome on mine and thought I'd be able to run tests with headless Chrome but hit this error;

Cannot destructure property `width` of 'undefined' or 'null'.
    at Window.getRect (/home/leedr/git/kibana/node_modules/selenium-webdriver/lib/webdriver.js:1435:13)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Also, I came across these notes for dev on wsl https://medium.com/@janelgbrandon/a-guide-for-using-wsl-for-development-d135670313a6

Are you using VS Code? Did you do this? (I haven't tried yet);
“terminal.integrated.shell.windows”: “C:\\WINDOWS\\System32\\wsl.exe”

And do you lnk your Windows C: drive like they do?
5. Create a link from your WSL to your C drive

[joshdover]

It sounds like if we go this route, we should at the very least provide some guidance in CONTRIBUTING.md on how to setup WSL for Kibana development.

[jbudz]

@LeeDr I run into issues with that and reporting too. Given the number of issues I think it makes sense to pick full support or no support. Getting CI setup to run native windows builds would go well with this.

[LeeDr]

To be clear, I'm OK if we decide to drop support for development on Windows. I could likely get WSL working well enough, but I'd probably not do that and just use Ubuntu instead. So, what @jbudz said.

[LeeDr]

@skearns64 @kimchy any thoughts on this overall? I don't know of a good way to gauge the impact on contributors. We don't want to alienate contributors but we also don't want to struggle with supporting an OS that certainly isn't used by most of the core Kibana team.

[tylersmalley]

I think it's helpful to provide more context here; we will plan to have a full guide to continued development on Windows using WSL2 which is supported by Microsoft. Development under native Windows is MUCH slower than even under WSL2 on the same hardware [1]. This is due to the file I/O performance under Windows and the sparse nature of a Node application.

Additionally, supporting Windows directly for development has substantial overhead and leads to Windows specific errors. Compare this to the fact our CI runs on Ubuntu, which is supported by WSL.

1: There is a 60-70% increase in performance when using WSL2 on the same hardware. To bootstrap all of the Kibana node modules from scratch (using Yarn cache to eliminate the network latency from the test) average times went from 843s to 330s. Clean went from 76s to 21s.

[LeeDr]

It seems you can't use WSL2 along with VirtualBox 5.x because of VT-x sharing (or lack of sharing).
Although there's a way to switch from WSL version 2 back to version 1, it does not revert settings which allows VirtualBox to work. And in fact, I haven't figured out a way to get VB 5.x working again :-( I'm on VirtualBox 5.2.36.

I've heard that some 6.x version of VirtualBox will work, but that the performance is very bad (I haven't tried myself yet).

[LeeDr]

Now that I'm back on WSL version 1 (because I also need to use VirtualBox), it doesn't look like I get the performance improvements Tyler had in WSL2. From https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes

"WSL 2 uses a Virtual Hardware Disk (VHD) to store your files ..."

In fact, I find that WSL is slower :-(
After bootstrapping, and cleaning, so I get yarn cached performance on bootstrap I get;

WSL (1) bootstrap - Done in 2058.47s
git-bash          - Done in 1401.88s

So then I thought, I'll just dd a 30GB file, format it ext3, and mount it at ~/git/. Then my small file writes will all be going to what is actually a single file on the Windows disk (more like WSL2 I thought). Unfortunately, mounting a loop device doesn't work on WSL1 (works on WSL2, but of course, isn't needed).

Since I do use VirtualBox, I timed bootstrap on a Ubuntu VM running on my Windows laptop - Done in 327.84s. This is almost exactly what Tyler got on WSL2.

My personal Intel Core-i5 CPU Ubuntu desktop with much lower hardware specs than my laptop beats them all with bootstrapping in 178s.

[kimchy]

I have been thinking about it, my biggest concern is that it will erode our ability to support windows over time. I mean, we don't really support windows for our packages, since we don't have an MSI installer for it (or for our full stack). I know this is unrelated, but I have seen it happening historically.

We do live in a different world where WSL exists, so if this works well, I am supportive of it. Especially if this type of development on windows is happening for node not only in the context of Kibana?

[lizozom]

I can confirm that using WSL2 works well and gives significant performance improvements compared to both running plain Ubuntu or WSL1 on Windows.

For anyone considering trying this out, these are the steps I took:

• Updated Windows 10 to the latest version
• Followed the steps covered in this tutorial, installing Ubuntu 18.04.
• Joined the Windows Insider Program and updated to the latest developer version of Windows 10.
• Followed the steps covered in the WSL2 tutorial.
• WSL2 tends to eat up your entire RAM. This solved it for me. Another solution is suggested here.

@tylersmalley However, I wasn't able to run functional tests with X410 getting warn Failure loading service "__webdriver__", even after following the steps you listed.

[spalger]

Looks like WSL2 is going to be easier to use soon https://www.infoq.com/news/2020/04/wsl-2-general-availability/

[kobelb]

Do we happen to have any telemetry data on how many Kibana developers/contributors are using Windows without WSL?

[tylersmalley]

Closing this discuss issue. We are working on documentation for using WSL and will use it to provide to WIndows developers for direct feedback.