You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whilst instead of saying docker run --rm -it <cumbersome list of args> <firecracker container name> cargo build, we just say devtool build to simplify the build process, it looks like the build-tool hasn't been tested for docker for Windows. Fundamentally, Windows doesn't have TTY so any attempt to break into shell with a docker run command i.e. , will return the input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty'. This is a common and well known compatibility issue running Docker on Windows, and I'd expect it to be the only real compatibility issue for the devtool.
This is the case for running Firecracker build on Docker for Windows (tested on Windows 10 Home Edition using the Docker Toolbox). The feature ought to be implemented since, well, Docker is for everyone right? So we just need to add support for that. There are a few options for this...
Adding flags to detect what operating system the user is running, and if a Windows host then run different commands. We could use an interceptor pattern to achieve this cleanly, or add a flag which detects whether the host OS is in a non-TTY environment, which I think in the context of docker would be more idiomatic (since that refers directly to the feature we're trying to implement).
Add a new path build-win.
Add mutator flags to the existing build arguments.
From a development experience point of view, I'd probably prefer to implement the first, however I just want to collect at least some opinions before committing to a feature, get something out by the end of today (or tomorrow) that works on my home machine, and create a PR which is open to comments and testing. So please comment below if developers have any preferences with regards to this.
The text was updated successfully, but these errors were encountered:
I've done some exploration and made some good progress on this, just trying to resolve some TTY/winTTY related issues. I've successfully detected the OS and manipulated the basepath (thank you sed) with the correct drives. Just working my way through your script.
Thanks for this. Been caught up recently here are the updates I made to the Bash script if anyone wants to pick this up in the interim caldempsey@1167340. Cleaned it up quite well I think, code is in line with your style. I'm also waiting to see what the Windows 10 shell integration going forward looks like as I know Microsoft are working on quite a bit. They're doing some further integration with core-Windows bash-like commands and emulation (outside the scope of Ubuntu for Windows). The only issue my version has here is outputting to TTY, the actual container spin-up stage and OS detection logic works well. Appreciate it if you checked it out!
Uh oh!
There was an error while loading. Please reload this page.
Whilst instead of saying
docker run --rm -it <cumbersome list of args> <firecracker container name> cargo build
, we just saydevtool build
to simplify the build process, it looks like the build-tool hasn't been tested for docker for Windows. Fundamentally, Windows doesn't have TTY so any attempt to break into shell with adocker run
command i.e. , will returnthe input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty'
. This is a common and well known compatibility issue running Docker on Windows, and I'd expect it to be the only real compatibility issue for the devtool.This is the case for running Firecracker build on Docker for Windows (tested on Windows 10 Home Edition using the Docker Toolbox). The feature ought to be implemented since, well, Docker is for everyone right? So we just need to add support for that. There are a few options for this...
Adding flags to detect what operating system the user is running, and if a Windows host then run different commands. We could use an interceptor pattern to achieve this cleanly, or add a flag which detects whether the host OS is in a non-TTY environment, which I think in the context of docker would be more idiomatic (since that refers directly to the feature we're trying to implement).
Add a new path build-win.
Add mutator flags to the existing build arguments.
From a development experience point of view, I'd probably prefer to implement the first, however I just want to collect at least some opinions before committing to a feature, get something out by the end of today (or tomorrow) that works on my home machine, and create a PR which is open to comments and testing. So please comment below if developers have any preferences with regards to this.
The text was updated successfully, but these errors were encountered: