flag redefined: kubeconfig: tf-operator.v1 and universal operator can not work together

[Jeffwan]

This is an issue found in #1315 tests. part of #1299

/opt/tf-operator.v1 flag redefined: kubeconfig
panic: /opt/tf-operator.v1 flag redefined: kubeconfig  -> 

goroutine 1 [running]:
flag.(*FlagSet).Var(0xc0000ca120, 0x1bd0d40, 0xc0001ce540, 0x195df71, 0xa, 0x197271c, 0x1b)
	/usr/local/go/src/flag/flag.go:848 +0x4ae
flag.(*FlagSet).StringVar(...)
	/usr/local/go/src/flag/flag.go:751
github.com/kubeflow/tf-operator/cmd/tf-operator.v1/app/options.(*ServerOption).AddFlags(0xc0001ce540, 0xc0000ca120)
	/go/src/github.com/kubeflow/tf-operator/cmd/tf-operator.v1/app/options/options.go:54 +0x8b
main.main()
	/go/src/github.com/kubeflow/tf-operator/cmd/tf-operator.v1/main.go:54 +0x50

Our goal is to have original tf operator and new universal operator working together. However, Addflag is called twice and report the error. See more details in #1315 (comment)

Seem there's no good way to workaround it. We can temporarily comment that line and ask user to use KUBECONFIG env instead

[Jeffwan]

I comment out //fs.StringVar(&s.Kubeconfig, "kubeconfig", "", "The path of kubeconfig file") at this moment.
If user like to use external kubeconfig, they have to use KUEBCONFIG at this moment. This is not a big problem as I think (most user still use in cluster config)

I will leave this open if there's an elegant way to claim it.

[Jeffwan]

This is not something we are worried about any more. We plan to cut v1.1-branch for old tf-operator. We don't necessarily need to support compatibility between two version in same branch.

[Jeffwan]

/close

[google-oss-robot]

@Jeffwan: Closing this issue.

In response to this:

/close

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.