Support Finch on Windows #492
Assignees
Labels
feature_request
New Feature Request for Finch
Comments
This was referenced Jul 21, 2023
ginglis13
added a commit
to runfinch/finch-core
that referenced
this issue
Jul 27, 2023
Issue #, if available: runfinch/finch#492 *Description of changes:* In order to facilitate Finch on Windows, we need a root filesystem. We will use this Dockerfile as a basis for that root filesystem - using `docker export` to turn a built container into an archived rootfs. For the scope of these changes, create the Dockerfile and an action that runs on changes to the file to build and push to ECR repo. The Dockerfile will be used to create a container such that we can export that container's fs as a tarball and compress it for use with WSL2. For now, we are including cloud-init (at least for the WSL2 rootfs) but need further investigation to determine if we can remove the package to further slim the rootfs.. In order to create the container used as an intermediate step to export its rootfs, we need to tell buildkit to load the image into Docker. See This exposes a limitation of buildkit to load multiplatform images: `buildx failed with: ERROR: docker exporter does not currently support exporting manifest lists` thus why the action runs two build-rootfs-image jobs - one for each arch. See docker/buildx#59 and docker/roadmap#371 Additionally, network performance of the arm64 build is quite slow - downloads of packages via dnf are on the scale of kb/s (but this has not been observed on Ubuntu or Alpine images) *Testing done:* Local copy in a private repo, [`act`](https://github.com/nektos/act) - [X] I've reviewed the guidance in CONTRIBUTING.md #### License Acceptance By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. Signed-off-by: Gavin Inglis <giinglis@amazon.com>
ginglis13
added a commit
to ginglis13/finch
that referenced
this issue
Jul 28, 2023
for Finch on Windows runfinch#492, we need to provide a rootfs to WSL2. This rootfs lives in our dependencies bucket, and will be updated from time-to-time for security patches, bug fixes, etc. This commit will automatically pull the most recent rootfs from the depenedencies bucket as part of the Sync Submodules action, which already handles pulling in the latest OS builds. Signed-off-by: Gavin Inglis <giinglis@amazon.com>
ginglis13
added a commit
to ginglis13/finch
that referenced
this issue
Jul 28, 2023
for Finch on Windows runfinch#492, we need to provide a rootfs to WSL2. This rootfs lives in our dependencies bucket, and will be updated from time-to-time for security patches, bug fixes, etc. This commit will automatically pull the most recent rootfs from the depenedencies bucket as part of the Update Deps action. Signed-off-by: Gavin Inglis <giinglis@amazon.com>
ginglis13
added a commit
to ginglis13/finch-core
that referenced
this issue
Jul 28, 2023
for Finch on Windows runfinch/finch#492, we need to provide a rootfs to WSL2. This rootfs lives in our dependencies bucket, and will be updated from time-to-time for security patches, bug fixes, etc. This commit will automatically pull the most recent rootfs from the depenedencies bucket as part of the Update Deps action. Signed-off-by: Gavin Inglis <giinglis@amazon.com>
1 task
ginglis13
added a commit
to ginglis13/finch-core
that referenced
this issue
Aug 1, 2023
for Finch on Windows runfinch/finch#492, we need to provide a rootfs to WSL2. This rootfs lives in our dependencies bucket, and will be updated from time-to-time for security patches, bug fixes, etc. This commit will automatically pull the most recent rootfs from the depenedencies bucket as part of the Update Deps action. This commit also updates the upload rootfs action to use better pathing than storing the rootfs at root level of S3 bucket. Signed-off-by: Gavin Inglis <giinglis@amazon.com>
ginglis13
added a commit
to runfinch/finch-core
that referenced
this issue
Aug 1, 2023
Issue #, if available: runfinch/finch#492 *Description of changes:* for Finch on Windows runfinch/finch#492, we need to provide a rootfs to WSL2. This rootfs lives in our dependencies bucket, and will be updated from time-to-time for security patches, bug fixes, etc. This commit will automatically pull the most recent rootfs from the depenedencies bucket as part of the Update Deps action. *Testing done:* locally run script with FINCH_ROOTFS_URL ?= https://deps.runfinch.com/finch-rootfs-production-amd64-000000000.tar.zst set in Makefile, observe update. - [x] I've reviewed the guidance in CONTRIBUTING.md #### License Acceptance By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. Signed-off-by: Gavin Inglis <giinglis@amazon.com>
1 task
|
Can we close this issue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the problem you're trying to solve?.
Windows users should be able to use Finch. I provided some thoughts on how this could be implemented below, but I'm happy to take comments on this issue directly to influence the design before the implementation is finalized.
Describe the feature you'd like
A user experience consistent with Finch on macOS, but for container developers that prefer Windows.
Additional context
Similar to #377, but for Windows instead of Linux.
Regarding implementation details, I think the ideal way to proceed is to add support for Windows to our dependencies, namely, Lima. This way, most of the work could be reused by other projects that depend on Lima, and the Finch changes would be minimal, and mostly around packaging and distribution.
Based on my research so far, it seems like WSL2 is the best way to implement this in Lima, via a new VM driver (similar to how there's a QEMU driver and a VZ driver in Lima already). WSL2 seems to be a long-term, Microsoft supported feature of Windows, so we don't have to worry about maintaining the Virtualization stack ourselves. However, this also means that we can't really contribute to bug fixes and adding new features to WSL2. Technically, there are two main points against WSL2: disk I/O speed and hardware support.
Disk I/O performance is limited because of the way files are shared between the main Windows filesystem and the Linux filesystem (plan 9 fs server). It's likely that the existing performance is good enough for most user's use cases though. It's possible that Microsoft addresses this concern over time.
Hardware support for WSL2 is limited to CPUs/Motherboards that have VT-x/VT-d / AMD-V / SVM support. Other options, like HyperV also have these hardware limitations. QEMU technically does not have this limitation as it can fall back to software virtualization, but this is not really practical for any sort of "good" user experience. Besides the hardware support, certain Windows features need to be enabled, but this can be automated by Finch or Lima directly and is not as much of an issue (will just require more careful error handling / messaging).
WSL2 VMs initialize from root filesystem archives instead of disk images (qcow2/img/iso), so we will also need to adjust our OS building process to support WSL2, and will need to adjust Lima to support these new root filesystem archives when using the WSL2 driver.
The text was updated successfully, but these errors were encountered: