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

--apiserver-names does not work as expected when you run minikube start a second time #8990

Closed
jemygraw opened this issue Aug 13, 2020 · 2 comments · Fixed by #9385
Closed
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/bug Categorizes issue or PR as related to a bug. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@jemygraw
Copy link

jemygraw commented Aug 13, 2020

Related issue: #8658

Steps to reproduce the issue:

  1. minikube start --apiserver-names=k8s-beta.example.com --apiserver-names=k8s-prod-replica.example.com

Version:

appdelivery@appdelivery-qvm-1:~$ minikube version
minikube version: v1.12.1
commit: 997fd89b9d3a0072e3112c79d906b6367e760473-dirty

Details: it is right when you first run the minikube start command, and when you re-run the minikube start with the same flags, it is wrong. So if you just run a new minikube, you will not reproduce it. I found the code which cause this error:

First Run
https://github.com/kubernetes/minikube/blob/master/cmd/minikube/cmd/start_flags.go#L162

startCmd.Flags().StringArrayVar(&apiServerNames, "apiserver-names", nil, "A set of apiserver names which are used in the generated certificate for kubernetes.  This can be used if you want to make the apiserver available from outside the machine")

Second Run
https://github.com/kubernetes/minikube/blob/master/cmd/minikube/cmd/start_flags.go#L539

cc.KubernetesConfig.APIServerNames = viper.GetStringSlice("apiserver-names")

Because the apiserverNames is first get by StringArrayVar which support the above format of --apiserver-names=k8s-beta.example.com --apiserver-names=k8s-prod-replica.example.com to specify multiple values for a single flag, but when you re-run minikue, it will use viper.GetStringSlice to get the values from the command line flags.viper.GetStringSlice supports the format of --apiserver-names=k8s-beta.example.com,k8s-prod-replica.example.com.

So when you output the values of the above code, it will output:

I0813 14:45:12.401533   90740 start_flags.go:539] existing: {v1.18.3 minikube minikubeCA [k8s-beta.duokexuetang.com k8s-prod-replica.duokexuetang.com] [] cluster.local docker    10.96.0.0/12    [] true false   8443 }
I0813 14:45:12.401574   90740 start_flags.go:540] viper: [[k8s-beta.duokexuetang.com,k8s-prod-replica.duokexuetang.com]]

I write a simple program to express what happens.

package main

import (
	"encoding/json"
	"fmt"
	"github.com/spf13/cobra"
	"github.com/spf13/viper"
)

var apiserverNames []string

type ClusterConfig struct {
	KubernetesConfig KubernetesConfig
}

type KubernetesConfig struct {
	APIServerNames []string
}

var startCmd = cobra.Command{
	Use: "start",
	Run: func(cmd *cobra.Command, args []string) {
		fmt.Println("apiserverNames=", viper.GetStringSlice("apiserver-names"))
		kubeConfig := KubernetesConfig{
			APIServerNames: apiserverNames,
		}
		clusterConfig := ClusterConfig{
			KubernetesConfig: kubeConfig,
		}
		data, _ := json.MarshalIndent(&clusterConfig, "", "    ")
		fmt.Println("Output=", string(data))
	},
}

func init() {
	startCmd.PersistentFlags().StringArrayVar(&apiserverNames, "apiserver-names", nil, "apiserver names")
	viper.BindPFlags(startCmd.PersistentFlags())
}

func main() {
	rootCmd := cobra.Command{}
	rootCmd.AddCommand(&startCmd)
	fmt.Println(rootCmd.Execute())
}

Output:

apiserverNames= [[hello,world]]
Output= {
    "KubernetesConfig": {
        "APIServerNames": [
            "hello",
            "world"
        ]
    }
}
@tstromberg tstromberg added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/bug Categorizes issue or PR as related to a bug. labels Aug 20, 2020
@sharifelgamal sharifelgamal added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Aug 26, 2020
@priyawadhwa
Copy link

Hey @jemygraw thanks for opening an issue for this bug. If you, or anyone else, would be interested in fixing this bug, feel free to assign yourself to this issue by commenting /assign.

@gm7y8
Copy link

gm7y8 commented Aug 31, 2020

/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/bug Categorizes issue or PR as related to a bug. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants