WSL2 SSH client setup instructions

[idagelic]

As explained in https://github.com/daytonaio/daytona/issues/282 - users may run into issues when running daytona on WSL2 and trying to daytona code into a workspace when using an IDE reliant on the SSH client.

We should extract the setup information/cautions from the original issue and provide them in the docs.

[stefanicjuraj]

Do you have a recommendation of where this could be added to fit best - in the VSCode IDE section?

Regarding this specific instruction, and others that might occur in the future, should there be a "troubleshooting" or similarly named section that would cover edge cases? I am thinking long-term if there will be more support-specific instructions to group them together into a section where there could be sub-sections covering edge cases, handling specific user errors, dealing with unusual or ambiguous requests, or providing guidance on what to do when standard procedures fail. I am guessing this would want to be avoided, but just as a suggestion.

@idagelic @Tpuljak @ivan-burazin

[idagelic]

I am all for a "FAQ" section of some kind, whether we decide to call it "Troubleshooting", "Knowledge base" or something else.

The kind of a set of instructions for this issue would belong there under a "WSL Support" page for example (the SSH client issue is no longer just VSCode specific). It wouldn't have to necessarily be something a user finds by clicking around, rather a page that is linked to them directly for reference or that they search for by writing in "wsl". For reasons like this one, I think a search functionality is something we will need soon and it might be more useful sooner than later; with this being the most intuitive position for it:

I am guessing this would want to be avoided, but just as a suggestion.

I agree that issues/friction should be avoided, but there will be of course some limitation/outside factors that are out of our hands so we should have docs covering ways to deal with those specific scenarios.

Thoughts by others on these two points? A troubleshooting section and a search functionality? Do we proceed with creating issues for these to discuss them further?

[Tpuljak]

https://docs.docker.com/#:~:text=Secrets-,Troubleshooting,-Community%20resources https://docs.docker.com/tags/troubleshooting/

Docker has a nice system with tags. They're not a specific section you can find but rather scattered around other sections. Adopting a similar flow might prove beneficial for us as well cause we could then provide troubleshooting for different parts of the app while still having a filter to quickly find all troubleshooting (or similar) sections.

Regarding the search, I already discussed it with @stefanicjuraj and we should definitely get on that asap.

[ivan-burazin]

This should be part of Windows installation (https://www.daytona.io/docs/installation/installation/#windows) as cant use it without doing this? Correct?

[idagelic]

The Windows installation can have a note box or something that links to this ("If you are developing inside of WSL, make sure to read these instructions")

People who use WSL know that they are really using Linux so they won't look at Windows steps. We might even add the a small note to the Linux installation to let them know.

Either way, I'd have the links lead to a separate page with the instructions.

Additional note is that you can still use Daytona in WSL without this (VSCode browser, neovim using Terminal SSH, etc) so it is not mandatory

[ivan-burazin]

In a note as @idagelic suggested is fine. My assumption is that the majority will use vs code so they will need to know this

[Tpuljak]

https://github.com/daytonaio/docs/pull/146#issuecomment-2332218570

Reopening due to ☝️