Skip to content
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

Windows release? #300

Closed
mattfarina opened this issue Jul 5, 2018 · 34 comments · Fixed by #661
Closed

Windows release? #300

mattfarina opened this issue Jul 5, 2018 · 34 comments · Fixed by #661
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@mattfarina
Copy link

There are releases for both Mac and Linux (appears to be POSIX based). Would it be possible to cross-compile to Windows and have a Windows release as well?

@droot
Copy link
Contributor

droot commented Jul 10, 2018

I think cross-compiling Kubebuilder binary itself should be easy because we use GoReleaser to generate the builds, packaging the dependencies for Windows is going to require some more work here. Happy to help if anyone wants to take this up.

@droot droot added the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label Jul 10, 2018
@p-bakker
Copy link

p-bakker commented Oct 12, 2018

If you want to run this on Windows, you could also enable the Windows Linux Subsystem on Windows
(10) and install for example Ubuntu from the Windows App store and just install and run the Linux version of Kubebuilder

https://github.com/michaeltreat/Windows-Subsystem-For-Linux-Setup-Guide

@mattfarina
Copy link
Author

@p-bakker It's worth noting that ~50% of devs use Windows and most don't use the subsystem for Linux.

@p-bakker
Copy link

true, but WSL is fairly new/gaining traction and while Devs use windows, I'd say most deployments are on Linux, so imho devs would be wise to get familiar with WSL and start making it part of their vocabulary as it gives them the opportunity to test more realistically (testing signals on windows for example won't get you far). Heck, even in VS Code you can now run your debug targets by adding a single property to the configuration.

Not saying there's no point in having native support on Windows, just noting there are alternatives which are pretty straight forward imho

@neelesh3710
Copy link

WSL does not fully support all development workflows. For example:

Can't run delve debugger on WSL: microsoft/WSL#2977

There is also issue running kubebuilder tests on WSL because etcd shipped with kubebuilder does not run under WSL.

Would be nice if the native windows version was available.

@alexeldeib
Copy link
Contributor

alexeldeib commented Apr 8, 2019

@droot Could you elaborate on packaging the dependencies for Windows is going to require some more work? Do you mean e.g. etcd/kube-apiserver/kubectl for testing? The only dependency I could find which did not have a windows build available was kube-apiserver.

With the two diffs below, I'm able to build and use Kubebuilder natively on windows. I'm happy to take this task up and do the work necessary to get it into mergeable state.

kubernetes-sigs/controller-tools#179
#661

@alexeldeib
Copy link
Contributor

alexeldeib commented Apr 8, 2019

For testing on windows, I used a container and volume mounted my dev directory so that I could run kube-apiserver. This is one of the areas that would require more work for a smooth experience, e.g. providing a predefined dev docker container or possibly running kube-apiserver (and ideally other elements) from a docker image during tests.

@droot
Copy link
Contributor

droot commented Apr 12, 2019

Could you elaborate on packaging the dependencies for Windows is going to require some more work? Do you mean e.g. etcd/kube-apiserver/kubectl for testing? The only dependency I could find which did not have a windows build available was kube-apiserver.

Yes, thats what I meant.

@alexeldeib
Copy link
Contributor

/reopen

@k8s-ci-robot
Copy link
Contributor

@alexeldeib: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@alexeldeib
Copy link
Contributor

@droot I marked this as fixed in the PR which was a mistake 😦 could you reopen?

@DirectXMan12 DirectXMan12 reopened this May 30, 2019
@DirectXMan12
Copy link
Contributor

sorry for the terrifically long delay here

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 28, 2019
@DirectXMan12
Copy link
Contributor

/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Sep 3, 2019
@DirectXMan12
Copy link
Contributor

we still need help for this. we'll want CI too

@chx
Copy link

chx commented Sep 18, 2019

Re #300 (comment) about WSL, Microsoft gave up on trying to translating syscalls and WSL2 is a very lightweight VM so now truly all Linux programs will work. Just sayin'.

@alexeldeib
Copy link
Contributor

alexeldeib commented Sep 18, 2019

I think it’s reasonable to tell windows users to run e2e tests agains kind, and set envtest to use existing cluster?

I regularly work on windows and linux and use kubebuilder fine with this approach on both. Some random characters in help text but that’s my biggest complaint.

Rest of testing can probably be done in Go and be x-plat?

@Aarthisk
Copy link

I am starting off with kubebuilder on windows- is the easiest option to build by myself?

@alexeldeib
Copy link
Contributor

That’s what I do

@DirectXMan12
Copy link
Contributor

It'd be nice to at least have nightly builds using cross-compile, I think (if anyone wants to pitch in) and a test on prow/travis that tries to cross-compile.

@Adirio
Copy link
Contributor

Adirio commented Oct 17, 2019

With both issues mentioned in #300 (comment) merged, is it possible to compile for windows straight away or do I need to change anything?

The mentioned tests issues are with projects build with kubebuilder or with the kubebuilder cmd? The first is not an issue as they will be tested in my CI machines which are non-windows.

@alexeldeib
Copy link
Contributor

You'll be fine. I did a sanity check right now:

git clone [email protected]:kubernetes-sigs/kubebuilder
cd kubebuilder
go build -o kubebuilder.exe ./cmd/
./kubebuilder.exe # works

@alexeldeib
Copy link
Contributor

alexeldeib commented Oct 17, 2019

Elaborating on my original comment, the test issues are related to running e2e tests for controllers built using Kubebuilder which depend on a full Kubernetes cluster. On Linux, you can use the etcd/apiserver binaries and the envtest package to quickly spin up a real backend. On windows, you can't run the apiserver binary, so this doesn't work.

Using kind works well as a backing cluster for envtest on windows. This will let you run full e2e with controllers made using kubebuilder/controller-runtime on your windows machine.

The tests for kubebuilder itself are a separate story.

@Adirio
Copy link
Contributor

Adirio commented Oct 17, 2019

I have a running kubernetes on windows (docker-for-windows). Well its actually not windows somehow as it is pulling the linux images from the manifests, but all the kubernetes cluster is accessible with kubectl from the windows command. Shouldn't that be enough for e2e tests?

@alexeldeib
Copy link
Contributor

alexeldeib commented Oct 17, 2019

See https://godoc.org/sigs.k8s.io/controller-runtime/pkg/envtest for requirements, but that will probably work. I can't say without more certainty without trying 😄

@Adirio
Copy link
Contributor

Adirio commented Oct 17, 2019

Which version of Golang are you using? I'm asking this to know if I must set go modules as I'm currently using 1.12.x which if I'm not mistaken is the last that doesn't have it turned on by default.

@alexeldeib
Copy link
Contributor

Correct, the above requires go modules (I always enable them by default in my environment)

Barring windows specific issues on this thread, slack channel is probably a better forum for discussion + q/a 🙂

@Aarthisk
Copy link

@alexeldeib
you said "Using kind works well as a backing cluster for envtest on windows. This will let you run full e2e with controllers made using kubebuilder/controller-runtime on your windows machine."

So forgive the novice question, but with a backing "real" k8s cluster, this should just work then? The issues you are pointing out are unit testing without a cluster which I can honestly live without.

@Adirio
Copy link
Contributor

Adirio commented Oct 18, 2019

I'm finding some issues with the paths inside the generated Makefile for the projects. To achieve compatibility with Windows I guess this generated Makefile (https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/scaffold/v2/makefile.go) needs to be either generic or specific for the target OS.

@DirectXMan12
Copy link
Contributor

happy to take fixes to make it windows-compatible (none of the core devs have windows machines, so it's a bit hard for us)

@Adirio Adirio mentioned this issue Mar 4, 2020
@camilamacedo86 camilamacedo86 added this to the next milestone Nov 3, 2020
@camilamacedo86 camilamacedo86 removed this from the next milestone Dec 1, 2020
@camilamacedo86 camilamacedo86 added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Dec 1, 2020
@MaxThom
Copy link

MaxThom commented Aug 10, 2021

This is how I installed kubebuilder on WSL2.

git clone https://github.com/kubernetes-sigs/kubebuilder.git
cd kubebuilder
make build
Session Only: export PATH=$PATRH:*<path_to_kubebuilder>*
On Reboot: sudo nano ~/.profile
Add export path at the end of the file: export PATH=$PATRH:*<path_to_kubebuilder>*

@ziyanli33
Copy link

You'll be fine. I did a sanity check right now:

git clone [email protected]:kubernetes-sigs/kubebuilder
cd kubebuilder
go build -o kubebuilder.exe ./cmd/
./kubebuilder.exe # works

@alexeldeib It works brilliant, however I am having issues when I use the command kubebuilder create api, which calls make generate. The problem is that, the Makefile used is written for Unix systems, so make generate reports error.

@THMAIL
Copy link

THMAIL commented Aug 17, 2022

it doesn't work at all !!!

I have tried , but when I execute "kubebuilder version", error occured and shows that
time="2022-08-17T15:25:25+08:00" level=error msg="could not get plugins root: Host not supported: windows" time="2022-08-17T15:25:25+08:00" level=error msg="Host not supported: windows" Version: main.version{KubeBuilderVersion:"unknown", KubernetesVendor:"unknown", GitCommit:"$Format:%H$", BuildDate:"1970-01-01T00:00:00Z", GoOs:"unknown", GoArch:"unknown"}

@camilamacedo86
Copy link
Member

Closed in favor of : #2940

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.