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

ServiceNodePortRange config no longer recognised #1359

Closed
georgecrawford opened this issue Apr 10, 2017 · 4 comments
Closed

ServiceNodePortRange config no longer recognised #1359

georgecrawford opened this issue Apr 10, 2017 · 4 comments

Comments

@georgecrawford
Copy link

Minikube version v0.18.0

Environment:

  • OS OS X 10.12.4 (16E195)
  • VM Driver xhyve (also a problem with virtualbox)
  • ISO version minikube-v0.18.0.iso
  • Install tools:
  • Others:

What happened:

Until recently, I could start minkube with --extra-config=apiserver.GenericServerRunOptions.ServiceNodePortRange=1-50000 and expose a service as a NodePort on port 80. Worked great. In minikube 0.18.0, this param no longer seems to be recognised:

Apr 10 21:54:17 minikube localkube[3097]: I0410 21:54:17.532142    3097 localkube.go:119] Setting GenericServerRunOptions.ServiceNodePortRange to 1-50000 on apiserver.
Apr 10 21:54:17 minikube localkube[3097]: W0410 21:54:17.532304    3097 localkube.go:121] Unable to set GenericServerRunOptions.ServiceNodePortRange to 1-50000. Error: Unable to find field by name: ServiceNodePortRange

What you expected to happen:
No errors in logs, and NodePort services can be assigned to any port in the selected range.

How to reproduce it
minikube start --vm-driver=$DRIVER --extra-config=apiserver.GenericServerRunOptions.ServiceNodePortRange=1-50000 and then minikube logs | grep ServiceNodePortRange to check for errors.

Anything else do we need to know:

@aaron-prindle
Copy link
Contributor

Can you try using config=apiserver.ServiceNodePortRange=1-50000? From the documentation it seems this setting might have moved as it appears to not be under GenericServerRunOptions anymore.

@aaron-prindle
Copy link
Contributor

Resolved, closing

@georgecrawford
Copy link
Author

Yep, that's it. Many thanks @aaron-prindle. Worth linking to #1006.

@gsaslis
Copy link

gsaslis commented Apr 29, 2018

didn't quite work for me, but good pointers here. I solved it with:
#2765 (comment)

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

No branches or pull requests

3 participants