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

Add 'native-ssh' flag to 'minikube start' and 'minikube ssh' #4510

Merged
merged 1 commit into from
Sep 6, 2019
Merged

Conversation

yinzara
Copy link
Contributor

@yinzara yinzara commented Jun 17, 2019

Docker machine gives an option for sshing into a running container of using the Golang SSH native client or using the external 'ssh' command line executable.

Normally, "docker-machine ssh" uses the "external" client by default and a "--native-ssh" flag must be passed to enable the native client.

Minikube by set the client to native by default with no option to change this behavior. This causes issues with some VM drivers.

Though the native SSH client for Golang is more efficient than the command line 'ssh' command, there are times in which using the 'ssh' CLI is necessary.

This PR adds a "--no-native-ssh" flag to the minikube start command an and associated "no-native-ssh" config option (through minikube config set no-native-ssh true.

@k8s-ci-robot
Copy link
Contributor

Welcome @yinzara!

It looks like this is your first PR to kubernetes/minikube 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/minikube has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

@k8s-ci-robot
Copy link
Contributor

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.


  • If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
  • If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
  • If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
  • Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: [email protected]

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. I understand the commands that are listed here.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. label Jun 17, 2019
@k8s-ci-robot
Copy link
Contributor

Hi @yinzara. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

@k8s-ci-robot k8s-ci-robot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Jun 17, 2019
@minikube-bot
Copy link
Collaborator

Can one of the admins verify this patch?

@@ -20,6 +20,7 @@ import (
"encoding/json"
"flag"
"fmt"
"github.com/docker/machine/libmachine/ssh"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this change looks odd

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. That was definitely added in error. I'll fix.

cmd/minikube/cmd/config/config.go Show resolved Hide resolved
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Jun 17, 2019
@@ -154,6 +157,7 @@ func init() {
startCmd.Flags().Bool(gpu, false, "Enable experimental NVIDIA GPU support in minikube (works only with kvm2 driver on Linux)")
startCmd.Flags().Bool(hidden, false, "Hide the hypervisor signature from the guest in minikube (works only with kvm2 driver on Linux)")
startCmd.Flags().Bool(noVTXCheck, false, "Disable checking for the availability of hardware virtualization before the vm is started (virtualbox)")
startCmd.Flags().Bool(noNativeSSH, false, "Disable using the native Golang SSH client and instead uses the command line 'ssh' command when accessing the docker machine. Useful for the machine drivers when they will not start with 'Waiting for SSH'.")
Copy link
Member

@medyagh medyagh Jun 17, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make the description shorter, instead of Useful for the machine drivers when they will not start with 'Waiting for SSH'. I would link to an issue or a docs.md

like see github.com/kubernetes/minikube/docs/drivers#nossh.md

or do you know list of all vm-drivers that have that problem to list here instead ? if we know that, does it worth to make an automatic option for specific drivers? we already created an automatic option for none driver.
#4465

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There have been NUMEROUS issues related to "Waiting for SSH" for almost every VM driver which is why I specifically mentioned it as a possible fix when you encounter that issue.

The issue is that it isn't "required" by the Hyperkit driver. It's required if you have a USB network adapter like a USB dongle or a docking station that provides wired network access for a laptop (which is why I made it an optional flag instead of setting it automatically for the hyperkit driver).

Copy link
Member

@medyagh medyagh Jun 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, I know this issue has happened for sure for none driver, I wonder if it has happened to virtualbox as well ? I would okay with testing this PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only debate with naming in this PR relates to the name of the arg itself.

Should it be "--no-native-ssh" since it mirrors the "--native-ssh" arg from 'docker machine ssh' and effectively affects its opposite or should it be "--external-ssh" (or maybe --ssh-cli) so that it implies what it actually does?

@medyagh
Copy link
Member

medyagh commented Jun 19, 2019

@minikubebot OK to test

@RA489
Copy link

RA489 commented Jun 19, 2019

@minikube-bot OK to test

@yinzara
Copy link
Contributor Author

yinzara commented Jun 26, 2019

I need a little help deciphering what went wrong. It seems the Linux-VirtualBox test somehow failed but I can't figure out what's causing it. Help!

@yinzara
Copy link
Contributor Author

yinzara commented Jun 28, 2019

I've rebased against master and force pushed. All builds are "Pending" now, does something need to be done?

@yinzara
Copy link
Contributor Author

yinzara commented Jun 28, 2019

Nvm everything is good now :) . Can I get a lgtm?

@medyagh
Copy link
Member

medyagh commented Jun 28, 2019

lets wait for @tstromberg's input

@k8s-ci-robot k8s-ci-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Jun 29, 2019
@RA489
Copy link

RA489 commented Jul 1, 2019

@minikube-bot OK to test

@yinzara
Copy link
Contributor Author

yinzara commented Jul 1, 2019

I still don't understand how the VirtualBox-Linux test is failing. My change is so minor and should have no affect unless specifically enabled (which it isn't by default). Is it possible this is unrelated to my changes? The errors are so cryptic I can't decipher what's going on.

@yinzara
Copy link
Contributor Author

yinzara commented Jul 1, 2019

2028 ssh_runner.go:101] SSH: docker load -i /tmp/k8s-dns-kube-dns-amd64_1.14.13

That seems to be the line that's erroring. All of the docker load... lines before it are passing but that one seems to fail.

@medyagh
Copy link
Member

medyagh commented Jul 2, 2019

I believe the vbox failing test was timing out

@medyagh
Copy link
Member

medyagh commented Jul 2, 2019

/retest this please

@yinzara
Copy link
Contributor Author

yinzara commented Jul 2, 2019

Yay! All we need is a lgtm :) . @tstromberg ?

@tstromberg
Copy link
Contributor

Though the native SSH client for Golang is more efficient than the command line 'ssh' command, there are times in which using the 'ssh' CLI is necessary.

First, thank you for this PR!

I want to make sure I understand the technical merits of adding another flag before LGTM'ing, as once we do, we are stuck supporting it for the long haul. Do you mind elaborating what specific use cases this flag this flag would be useful for in the PR description and help text?

If the minikube VM used an exotic authentication mechanism, I would completely understand why using the external ssh mechanism is useful, but I don't yet understand other reasons for it. I would expect that the packets will be routed similarly.

In general, I would personally would prefer having an automatic fallback/selection mechanism for flags like this, rather than forcing the user to fail first and try again, but I don't understand enough about the problem yet to have a more specific recommendation.

@yinzara
Copy link
Contributor Author

yinzara commented Jul 2, 2019

Unfortunately the reason for needing this flag are not always clear. In my example with the Hyperkit driver, when a USB network adapter was added to the system, the Golang SSH library was unable to connect to the Hyperkit container. It just sat waiting forever at "Waiting for SSH" without ever timing out. It was literally frozen and didn't time out (so I couldn't have "fallen back automatically" even if I wanted to).

While I would love to have solved the cause for this, there are TONS of issues over the years related to issues with "Waiting for SSH..." that trying this option may have allowed a user to continue. If we know the command line SSH client does work, having a method for enabling this is necessary (as docker-machine ssh already does). The docker-machine library doesn't even provide more information about the use of this flag other than its existence, how to use it, and that it may provide different functionality.
https://docs.docker.com/machine/reference/ssh/

To be perfectly honest, I'd actually rather model the docker-machine ssh library and change the default behavior to use the CLI like docker-machine does and provide a "--native-ssh" flag just like they do. However, that would cause a change in the default behavior of minikube and is a much bigger ask.

@yinzara
Copy link
Contributor Author

yinzara commented Jul 2, 2019

Looks like this was changed in 2017 as part of:
eafb4fc

@RA489
Copy link

RA489 commented Jul 3, 2019

@minikube-bot OK to test

@@ -160,6 +163,7 @@ func init() {
startCmd.Flags().Bool(gpu, false, "Enable experimental NVIDIA GPU support in minikube (works only with kvm2 driver on Linux)")
startCmd.Flags().Bool(hidden, false, "Hide the hypervisor signature from the guest in minikube (works only with kvm2 driver on Linux)")
startCmd.Flags().Bool(noVTXCheck, false, "Disable checking for the availability of hardware virtualization before the vm is started (virtualbox)")
startCmd.Flags().Bool(noNativeSSH, false, "Disable using the native Golang SSH client and instead uses the command line 'ssh' command when accessing the docker machine. Useful for the machine drivers when they will not start with 'Waiting for SSH'.")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Boolean flags should not be named with a negative prefix, because otherwise it is really difficult to understand what this means:

--no-native-ssh=false

I regret that we did not catch this for --no-vtx-check.

Copy link
Contributor Author

@yinzara yinzara Jul 11, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So then should we change the parameter to be "--native-ssh" to match with the corresponding parameter in docker-machine ssh and the default behavior to use the "External" CLI SSH (as it was before) eafb4fc (and as it is in docker-machine ssh) or should I change the parameter to be "--external-ssh" and maintain the current default behavior (even though it is the opposite of docker-machine ssh)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. Name the flag --native-ssh, but do not yet change the default behavior.

@tstromberg tstromberg added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 17, 2019
@tstromberg
Copy link
Contributor

Needs rebase.

@yinzara
Copy link
Contributor Author

yinzara commented Jul 17, 2019

lol I think you missed the two options. I can either name the parameter "--native-ssh" (like docker-machine ssh names it) and change the default behavior to use External SSH (like docker-machine ssh) by removing the line from the eafb4fc or I can name the parameter "--external-ssh" and leave the default the way it is currently. Adding a "--native-ssh" parameter would do nothing unless I change the default behavior.

@RA489
Copy link

RA489 commented Jul 18, 2019

@yinzara Please resolve the conflicts.

@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 19, 2019
@sharifelgamal
Copy link
Collaborator

Could you change the name to be --native-ssh while still defaulting the behavior to true? Ideally changing the default behavior would be in a separate PR. This way, it can still be set to false when needed.

@yinzara
Copy link
Contributor Author

yinzara commented Sep 5, 2019

I don't know how to make myself clearer lol

If I call it --native-ssh while still defaulting the native behavior to true, this PR will literally do nothing. That would mean if I call "minikube ssh" it would use native SSH no matter if I use the --native-ssh flag or not and there will be no way of using the external CLI ssh (the exact reason for this PR).

There are literally only two options (and a variation on the 1st in naming).

Call it --no-native-ssh (this is the current state of the PR) or --external-ssh and keep the default the same (i.e. native SSH) as it is now (even though its the opposite of docker-machine ssh). Specifying the flag would cause it to use the "external" CLI SSH.

OR

Call it --native-ssh (like docker-machine ssh) and change the default to use "external" CLI SSH matching the behavior of docker-machine ssh. Specifying the flag would cause it to use native SSH.

@sharifelgamal
Copy link
Collaborator

--native-ssh=false would do exactly what you want without having to change the parameter name or the default behavior.

@yinzara
Copy link
Contributor Author

yinzara commented Sep 5, 2019

INTERESTING!

I didn't realize that was an option (I can't see any other minikube options like that).

I guess I could call it --native-ssh and make it default to "true" when not specified but if specified as false, follow the value given. Then if we change the default behavior, the CLI flag doesn't change. I didn't realize viper had that ability.

@k8s-ci-robot k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 6, 2019
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: yinzara
To complete the pull request process, please assign sharifelgamal
You can assign the PR to them by writing /assign @sharifelgamal in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@yinzara
Copy link
Contributor Author

yinzara commented Sep 6, 2019

There. Rebased against master and renamed to --native-ssh (where --native-ssh=false will enable use of the "external" CLI ssh).

Also added the flag to the minikube ssh command

@yinzara
Copy link
Contributor Author

yinzara commented Sep 6, 2019

/assign @sharifelgamal

@sharifelgamal
Copy link
Collaborator

Excellent, thanks for fixing that!

@sharifelgamal sharifelgamal changed the title Add 'no-native-ssh' flag to 'minikube start' Add 'native-ssh' flag to 'minikube start' and 'minikube ssh' Sep 6, 2019
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 6, 2019
@sharifelgamal sharifelgamal merged commit e974ce3 into kubernetes:master Sep 6, 2019
@vmvmpvm
Copy link

vmvmpvm commented Jul 31, 2020

Does this flag work?

I have minikube version 1.12.1, I still cannot use external ssh, I am running below command on Windows 10 using Hyper-V.

minikube start -v=8 --alsologtostderr --driver=hyperv --force --native-ssh=false

@yinzara
Copy link
Contributor Author

yinzara commented Jul 31, 2020

Yup we use it all the time and it works great. What do you mean by "I still cannot use external ssh"?

@vmvmpvm
Copy link

vmvmpvm commented Jul 31, 2020

Sorry, I should have provided more details, it always uses native ssh in my case

I am using minikube version: v1.12.1.

I execute below command

minikube start -v8 --alsologtostderr --profile minikube03 --driver hyperv --force --hyperv-virtual-switch "External Switch" --native-ssh=false

I see it is using native ssh

I0731 15:17:41.393688    8300 main.go:115] libmachine: **Using SSH client type: native**
I0731 15:17:41.394690    8300 main.go:115] libmachine: &{{{<nil> 0 [] [] []} docker [0x7b7070] 0x7b7040 <nil>  [] 0s} myvmip 22 <nil> <nil>}
I0731 15:17:41.395689    8300 main.go:115] libmachine: About to run SSH command:
sudo poweroff
I0731 15:17:52.360497    8300 main.go:115] libmachine: Error dialing TCP: dial tcp myvmip:22: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
I0731 15:18:02.398113    8300 main.go:115] libmachine: Error dialing TCP: dial tcp myvmip:22: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
I0731 15:18:16.363667    8300 main.go:115] libmachine: Error dialing TCP: dial tcp myvmip:22: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
I0731 15:18:26.399598    8300 main.go:115] libmachine: Error dialing TCP: dial tcp myvmip:22: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
....

How do I make it detect my External SSH?, Just fyi, when I run minishift it calls my external ssh just fine.

@vmvmpvm
Copy link

vmvmpvm commented Jul 31, 2020

using Hyper-V on Windows 10

@vmvmpvm
Copy link

vmvmpvm commented Jul 31, 2020

My external ssh config is configured to map myvmip ssh to a forwarded port, I need minikube to use the external ssh config for it to work.

@sharifelgamal
Copy link
Collaborator

@vmvmpvm I've opened #8907 to fix your issue.

@vmvmpvm
Copy link

vmvmpvm commented Aug 3, 2020

Thanks @sharifelgamal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants