Skip to content

Addding support for dev-tool build on Windows. #1080

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
caldempsey opened this issue May 3, 2019 · 3 comments
Closed

Addding support for dev-tool build on Windows. #1080

caldempsey opened this issue May 3, 2019 · 3 comments
Assignees

Comments

@caldempsey
Copy link

caldempsey commented May 3, 2019

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...

  1. 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).

  2. Add a new path build-win.

  3. 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.

@caldempsey
Copy link
Author

caldempsey commented May 3, 2019

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.

@dhrgit
Copy link
Contributor

dhrgit commented Jun 24, 2019

Closing this, since there's been no recent activity on it. Please reopen if needed.

@dhrgit dhrgit closed this as completed Jun 24, 2019
@caldempsey
Copy link
Author

caldempsey commented Jun 25, 2019

@dhrgit Hi dan,

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants