minikube fixes and hyperkit driver #40188
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nicknovitski
force-pushed
the
minikube-hyperkit
branch
from
53b07a9
to
2994aa4
Compare
nicknovitski
force-pushed
the
minikube-hyperkit
branch
from
2994aa4
to
9583d2c
Compare
|
I believe the ld flags I added in order to download kubeadm also fix #31602, which means we don't need to download localkube ourselves and pass it through the binary data. I've verified that I can delete the local cache, run |
nicknovitski
force-pushed
the
minikube-hyperkit
branch
from
9583d2c
to
8150b56
Compare
|
I found a way to disable the kubectl download message when generating shell completions, and so I removed kubernetes/kubectl as a dependency entirely. I don't know if that's ideal, since normal usage of minikube requires kubectl, and minikube will download kubectl on its own if kubectl isn't installed. Maybe in nixpkgs terms it's a native build input? |
|
@GrahamcOfBorg build minikube |
|
Success on aarch64-linux (full log) Attempted: minikube Partial log (click to expand)
|
|
Failure on x86_64-linux (full log) Attempted: minikube Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: minikube Partial log (click to expand)
|
This gives a valid default version when minikube attempts to download localkube, kubeadm, and other binaries, and makes downloading and vendoring localkube as binary data unnecessary.
|
So a compile error in xen? Hmm. Well, I'll rebase and see if that changes anything. |
nicknovitski
force-pushed
the
minikube-hyperkit
branch
from
8150b56
to
593035c
Compare
Did you solve this error? Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation for this change
My friends develop on macs and run what they develop on kubernetes. I couldn't get any other minikube drivers to work on our machines. minikube v0.26.1 adds hyperkit as a supported driver (apparently it will be the recommended one soon), and I was able to get it to work.
This PR should be treated very skeptically, because it's technically adding a broken feature: minikube refuses to run the driver unless it has the setuid flag. I tried patching out that check, but it seems that only binaries with that flag can successfully communicate with vmnet. If you don't run
chmod u+s $storepath/bin/docker-machine-driver-hyperkit, you can't use it.I don't mind running that command, but I don't know if it's right to put something like this in nixpkgs. Is there a good non-NixOS approach to things like this?
Things done
build-use-sandboxinnix.confon non-NixOS)[ ] NixOS[ ] other Linux distributions[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)[ ] Tested compilation of all pkgs that depend on this change usingnix-shell -p nox --run "nox-review wip"./result/bin/)