Decisions and Plan for Linux & Windows Support

[rickmanelius]

Overall Objective

The current team is primarily using macOS for development purposes and is not currently performing any manual testing on Linux and (more importantly) Windows. Given that we want/need to be able to support the big three (mac, Windows, and Linux), we need to ensure that they are all given a 1st class priority.

That said, we need to properly scope this so that we don’t become buried with keeping up with every distribution + version of Linux and every version of Windows. Therefore, it’s important that we find a balance point.

Acceptance Criteria

• Test v0.1 to v0.3 functionality on Windows 10.
• Test v0.1 to v0.3 functionality on Ubuntu 16.04.2 LTS.
• Inventory any OS specific nuances and/or issues.
• Determine a high level LOE for addressing said issues.
• Decide whether or not to expand Linux support beyond Ubuntu 16.04.2 LTS.
• Update readme to reflect current OS support.
• Update roadmap to reflect when support for each OS will be provided.
• When and where applicable, create additional issues to track future recommendations based on this research.

[rickmanelius]

This is now actionable, and potentially something we can/should separate into separate issues given that multiple people could work on this in parallel.

[rfay]

FWIW, I have used on Ubuntu 14.04 without any particular trouble (but without a lot of intensity), and all of our tests run on Ubuntu 14.04. Lots of gotchas getting Windows going, but could be fun.

[tannerjfco]

I also somewhat regularly develop and test ddev on Ubuntu 16.10, and haven't hit any notable issues in the usage I've had so far. That said, I have not done any actual web development with the tool on Linux.

[beeradb]

Our best path towards windows support in the near term may be via https://msdn.microsoft.com/en-us/commandline/wsl/about

[rfay]

Stackexchange recipe for docker on Windows Bash.

[rfay]

I did a kick-the-tires on Fedora 25 Workstation, and had no real trouble beyond understanding how to set up docker/docker-compose properly there. These are really the same problems with any linux, just slightly different varieties of setup.

1. Install docker-ce correctly, https://docs.docker.com/engine/installation/linux/fedora
2. Enable/start sudo systemctl start docker && sudo systemctl enable docker
3. Add user to docker group, then log out and log back in again.

[rickmanelius]

Another item to consider: file mounts (capabilities, complexity, and performance). See #208.

[rfay]

What I've learned so far is mostly incorporated in #209

There are at least 3 ways we can do docker on Windows:

1. Docker For Windows - requires Windows Pro, doesn't work on Windows Home due to lack of HyperV. As a result, I haven't been able to test it. Uses binary compiled for WIndows.
2. Docker Toolbox, which runs a Virtualbox VM. I've currently focused most effort on this one. Uses binary compiled for WIndows.
3. A composite environment under Windows Bash, see stackexchange recipe. This will require that the $DOCKER_HOST be set correctly, the same as in option 2. I look forward to seeing if this is possible. Uses binary compiled for Linux.

• ddev has to respect environment variables instead of assuming that everything is localhost http:
  • DOCKER_HOST in the form tcp://192.168.59.103:2375
  • DOCKER_CERT_PATH is fullpath to the ssl certificate
• Docker toolbox uses ssl, so GetDockerClient() has to use docker.NewTLSClient() instead of just docker.NewClient(). Current code makes this decision based on existence of DOCKER_CERT_PATH.
• Our current build works on windows in the msysgit environment (with rooted paths that don't have a colon), but only if minor change of homedir to /c/Users/ instead of c:/users. (We aren't able to run the docker run on the golang-build-container and mount it properly with a colon in the path. This is a docker issue unrelated to anything with ddev. There may be workarounds, especially if it's possible to mount a docker volume with a relative path.)
• import-db doesn't work, I don't yet understand why.
  importPath, err := appimport.ValidateAsset(imPath, "db") doesn't seem to return the right path - all garbaged up.
• all 4 containers are running
• The nginx proxy container gives up every time it contacts the nginx container - the keepalive is killed.
• I removed the ddev PrepareDirs from app init, and that broke test because .ddev/data didn't get created. Can probably do it to ensure those dirs are there instead of actually creating them (and failing).
• The sudo+etc/hosts approach certainly doesn't work on Windows, although there may be a way to launch ddev with admin privileges another way.
• ddev ssh doesn't work because it uses drud-go version of NewClient() (but that's fixed in Tanner's multi-compose Support multiple compose files, refactor compose commands #198)

[rickmanelius]

Initial Feedback to @rfay's review of Windows #196 (comment).

• Option 1: Windows Pro does add a $200 cost, which might price out people.
• Option 2: Docker Toolbox. My only concern is that this adds a layer of abstraction in the way. Essentially, one needs a VM in order to then run containers. At that point, I can see some end-users simply opting for a straight up VM solution, although we do have the advantage of being able to be a singular tool that works with multiple providers.
• Option 3: This to me seems like it would be the one that would best balance adoption and not creating the overhead of using an additional VM to use a docker solution. I'm biased towards exploring this more, even if it adds a bit more to the setup/installation efforts. It also seems like it could work in parallel to those that can opt for the Windows Pro version.

There is a lot to consider here, but I would imagine that if cost is a driving factor, an end-user might be more likely to adopt Ubuntu. Of course there are a lot of people using cheap windows laptops without a significant amount of RAM. That's where option 3 might provide them a path forward without the overhead of a VM.

Regarding your testing, it does sound like we'd have to audit certain functionality so that our commands work universally. I'm assuming once your PR is accepted, we can run all of our unit tests against Windows so we can chase down these discrepancies while not introducing regressions on macOS?

[rickmanelius]

A reminder, the scope of this ticket is testing, getting an inventory of OS specific discrepancies, and getting to a decision on what we'll support and when in the roadmap. So far things look promising, and we can plan on support (with caveats) for some Linux variants and Windows 10.

[beeradb]

Just a note, we are using goodhosts for host file management. It does claim to have windows support. Making that work is probably more a matter of figuring out privilege escalation (strongly assuming it's needed) on windows.

[tannerjfco]

• It looks like Windows 10 Home users can upgrade to Pro for $100 vs $200. Whether or not their machine shipped with Pro depends on whether they bought a personal or business class machine, or otherwise chose to upgrade to Pro at time of purchase. Still noteworthy that Docker for Windows support could mean an additional expense to users. It would be helpful to understand how many users in our demographic are running Home vs Pro, but unfortunately I couldn't find any existing public data with that specificity. Overall, I do think targeting Docker for Windows should be our end goal.
• I'm wary of working to provide support for what's considered the legacy desktop solution by Docker. It seems like most efforts moving forward are focused on Docker for Mac & Windows. This would also mean another virtualization environment with performance issues to contend with. I think our efforts are best focused ensuring best performance possible leveraging virtualization from the OS
• I'm in favor of supporting this approach, but not certain where it fits in. If it's a quick way to get Windows support soon, then I'm for doing it with the expectation we would circle back for proper Windows support. It may also prove to be a nice to have that should be considered down the road. It's worth noting WSL is very much in beta, and things could still change quite a bit as it evolves. We also don't know if this feature will end up being a Pro-only feature once it reaches maturity, or if it will continue to be available for all editions.

[rickmanelius]

My vote for Windows would be short term option 3 (WSL) mid to long term option 1 (Docker for Windows). If the team feels strongly enough to invert them, then we will need to purchase licenses sooner rather than later. Also, can we run Circle CI tests against Pro?

I personally have little interest in option 2 because I think it will hit its end of life in the near future and it adds more overhead than it's worth, but like Tanner called out, I'm not sure what market demographics are to make an informed decision with actual data.

[rfay]

We dan't run circle tests against any windows project, sadly. There are probably other services that allow us to do windows.

I still hope to get to WSL today, but can't claim that it's do-able at this point.

[rickmanelius]

So far the focus of this ticket has largely been on Windows, and that is fair given the concern that supporting Windows will be a much heavier lift than Linux. However, I would like to nail down what we officially support on the Linux side while providing the caveat that users with other distributions can certainly try. I also imagine that this selection might be influenced the the OS selection we use for other DRUD products in production, but that need not be a strict requirement.

[rickmanelius]

Thanks, @rfay! That nuance (not being able to test with Circle CI) might warrant a caveat "we support, but cannot run automated tests to capture regressions".

[beeradb]

My vote is to commit to supporting Ubuntu/Debian/Fedora. I think we can commit to good-faith effort on all other distros as well, but the more obscure the distro you use, the more patient you are going to need to be if issues pop up. I think people running fringe distros like gentoo generally have a frontier mentaility anyway :)

[rickmanelius]

@beeradb That list works for me re:Linux. We may need to specify version numbers (e.g. Ubuntu 16.04 LTS) or parameters (Ubuntu: 2 Most Current LTS Versions). Assuming the former, I would suggest we state:

• Ubuntu 16.04 LTS
• Debian Jessie
• Fedora 25

And then note, as you've mentioned, that older versions and other variants may work but require a little more hand-holding/tweaking.

[rfay]

We have a lot of technical capability here. There are significant issue to be considered besides that:

1. Support level required. For example, if we support 3 versions of Linux, we probably have to document the Docker install on each separately. And we certainly need a way to replicate customer environments.
2. Infrastructure (and infra maintenance) requirements: For Windows, for example, we really would need automated testing, which means we have to get it and maintain it, and then solve bugs that come up.

[rickmanelius]

Updated the issue summary to reflect the remaining items. Once we have the final Windows report (OS pain points, LOE to address, specifics on the methodology we will support), we can update the roadmap regarding when we will support Windows and to what extent.

[rickmanelius]

While this ticket is technically still open to get the documentation regarding OS specific issues, the primary outcomes intended for v0.4 from the perspective of an end-user have been achieved. Updating the issue summary to note future items and outcomes from this thread will be moved to other issues.

[rfay]

WIndows Comments:

Windows caveats:

• Version: I recommend that we support Windows 10 Professional using the Windows build of ddev. There are multiple other approaches and permutations, and some of them actually work, but I believe this is the mainline approach. Windows 10 Pro is a $99 upgrade to Windows Home, and should be pretty common out there.
• Docker for Windows only (not docker toolbox)

Infrastructure and planning:

• We need automated testing (discussed below)
• /etc/hosts management may need to be improved (Currently it asks for the site to be added to /etc/hosts even if it's there) - Also we may want to figure out how to allow them to do this automatically.

Documentation:

• We probably need separate basic documentation for Windows. Otherwise it will be stilted and hard to test. I wouldn't be surprised if it can link to some of the same things, but really we should be talking about ddev.exe and using windows paths, etc.

Building and testing

• Currently building and testing are best done using make, and the whole system is notoriously hard to use on Windows because it uses unix tools like rm and yet has to use the windows docker.exe. It may be a rethink for us to build on Windows - build-tools is definitely not set up for it.
• Full testing is normally done via make, which is not currently working. We can probably find a technique, but it's awfully hard right now.
• We need automated testing. The only integration listing in github's integration listing that mentions windows is Appveyor. It is free for open-source projects, which is nice. The private repo price plans run from $29-$99.

To me the biggest concern right now is building and testing, because I've broken my head on it from a few different angles. I think maybe working together with another team member we might come up with an alternate approach, but I'm stuck right now. Also, my current Windows machine is horrendously slow, which tends to put an end to things.

If Windows is important to us (probably) we'll have to actually use it a bit more to see what the actual results are in action.

[rickmanelius]

Hi @rfay. Thanks for this. I've updated the issue summary to indicate the summarization of the pain points and the assumption that this is a relative high LOE (assumed > 1 week to address these items). Seems we need to break out tickets related to the following:

• Documentation:
  • Specifying the supported Windows approach (Windows 10 Pro).
  • Specifying specific installation instructions.
• Build/Testing:
  • Improvements to the process so we have automated test coverage and better build support.
• Windows Compatibility
  • Addressing areas where linux/macOS assumptions fail (/etc/hosts, linux commands, .exe naming convention requirements on Windows, etc.).

[rickmanelius]

Placeholder children issues created. Closing out! Thanks, everyone on this HUGE issue!!!