Skip to content
This repository has been archived by the owner on Jun 29, 2022. It is now read-only.

cli/cmd: rename --kubeconfig flag to --kubeconfig-file #602

Merged
merged 5 commits into from
Jun 18, 2020

Conversation

invidian
Copy link
Member

@invidian invidian commented Jun 9, 2020

This PR renames --kubeconfig flag to --kubeconfig-file to avoid automatic reading of KUBECONFIG environment variable by viper and adds explicit read of KUBECONFIG variable after cluster configuration in the hierarchy, when selecting kubeconfig file to use.

For the time being, there is no tests for this patch, as testing that is not trivial to implement (involves creating lokocfg configuration file in temporary directory, testing private method, and testing viper flags parsing.

Closes #595.

@invidian invidian force-pushed the invidian/rename-kubeconfig-flag branch from 4133c67 to 6f16108 Compare June 9, 2020 18:59
@invidian invidian force-pushed the invidian/rename-kubeconfig-flag branch 2 times, most recently from d39d68b to ad712a7 Compare June 10, 2020 08:29
@invidian
Copy link
Member Author

For the time being, there is no tests for this patch, as testing that is not trivial to implement (involves creating lokocfg configuration file in temporary directory, testing private method, and testing viper flags parsing.

It turns out, I introduced some other bugs to the implementation, so I decided to write tests for it, even though they are not great.

cli/cmd/root.go Outdated
Comment on lines 59 to 60
"Path to kubeconfig file, taken from the asset dir if not given or from KUBECONFIG "+
"environment variable and finally falls back to ~/.kube/config")
Copy link
Contributor

Choose a reason for hiding this comment

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

We can take this opportunity to improve the text a bit.

Suggested change
"Path to kubeconfig file, taken from the asset dir if not given or from KUBECONFIG "+
"environment variable and finally falls back to ~/.kube/config")
`Path to a kubeconfig file. If empty, the following precedence order is used: 1. cluster asset dir when a lokocfg file is present in the current directory 2. KUBECONFIG environment variable 3. "~/.kube/config"`)

cli/cmd/utils.go Outdated
// flag or environment variable. Then the asset directory of the cluster is searched
// and finally the global default value is used. This cannot be done in Viper
// because we need the other values from Viper to find the asset directory.
// getKubeconfig finds the kubeconfig to be used. The preference is following:
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// getKubeconfig finds the kubeconfig to be used. The preference is following:
// getKubeconfig finds the kubeconfig to be used. The precedence is the following:

cli/cmd/utils.go Outdated
// - --kubeconfig-file flag OR KUBECONFIG_FILE environent variable.
// - Asset directory from cluster configuration.
// - KUBECONFIG environment variable.
// - ~/.kube/config path, which is kubectl default one.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// - ~/.kube/config path, which is kubectl default one.
// - ~/.kube/config path, which is the default for kubectl.

cli/cmd/utils.go Outdated
Comment on lines 141 to 142
// assetsKubeconfigPath reads the lokocfg configuration and returns
// path to kubeconfig file in it.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// assetsKubeconfigPath reads the lokocfg configuration and returns
// path to kubeconfig file in it.
// assetsKubeconfigPath reads the lokocfg configuration and returns
// the kubeconfig path defined in it.

@@ -0,0 +1,184 @@
// Copyright 2020 The Lokomotive Authors
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd like a test where both the KUBECONFIG flag is set and the lokocfg file is present to make sure it takes the file defined in the lokocfg. This is the most dangerous case IMO.

@ipochi
Copy link
Member

ipochi commented Jun 18, 2020

@invidian @iaguis

  1. I think that we should not use ~/.kube/config to fall back.

  2. Having KUBECONFIG_FILE environment variable gives an irritating behavior to the user as lokoctl is not a replacement for kubectl.

Even after installing the component by setting the KUBECONFIG_FILE environment variable, a user still interfaces the cluster with kubectl or in some cases helm. In such a scenario kubectl or helm is pointing to KUBECONFIG env variable or ~/.kube/config and lokoctl to KUBECONFIG_FILE.

Consider the the simplest scenario :

  1. Installed a component X with KUBECONFIG_FILE env var set.
  2. Need to get some logs of the component via kubectl, now I need to set the KUBECONFIG to the Lokomotive managed cluster in order to perform operations.

IMO, we should just have a flag --kubeconfig-file in lokoctl without KUBECONFIG_FILE env var.

Can we perhaps use Extensions (not sure how extensions is used, I've never seen it in a kubeconfig file) in the kubeconfig file to specify the additional cluster information as managed by Lokomotive. If the KUBECONFIG or current context is not referring to the same then we print out a message to the user for confirmation before proceeding ?

@invidian
Copy link
Member Author

I agree with Imran, that having this env variable is not really desired. Unfortunately, this is a side effect of the cobra. I'm not sure if we can disable env variable reading for just one flag.

@iaguis
Copy link
Contributor

iaguis commented Jun 18, 2020

Just as a reminder, my main focus for this PR is fixing the following case (which happened to me twice with bad consequences):

  1. A user runs lokoctl component apply from their cluster directory.
  2. The user has $KUBECONFIG set to another cluster, probably not even managed by Lokomotive.
  3. The components are applied to the cluster defined in $KUBECONFIG instead of the Lokomotive cluster (!)

I agree the $KUBECONFIG_FILE env var doesn't make sense. If it's not possible to disable it from cobra/viper I think just keeping it undocumented should be fine.

Regarding falling back to ~/.kube/config if there's no $KUBECONFIG and the user is not in a Lokomotive cluster directory I'm on the fence.

On the one hand kubectl falls back to ~/.kube/config so it makes sense if we do the same and commands to kubectl and lokoctl would apply to the same cluster. On the other hand this behavior might be dangerous and as a caution we might want to forbid it and ask the user to set $KUBECONFIG.

Since falling back to ~/.kube/config is already happening now, we can keep it and decide later if we want to change this behavior.

This also renames environment variable equivalent of old flag, which was
KUBECONFIG to KUBECONFIG_FILE.

This is to avoid prefering KUBECONFIG environment variable over
cluster configuration, which is happening right now, as we treat
--kubeconfig flag and KUBECONFIG environment variable as the same thing,
implicitly via 'viper.AutomaticEnv()' call.

The order of selecting kubeconfig file to use should be following:
1. --kubeconfig-file flag OR KUBECONFIG_FILE environment variable
2. cluster configuration in working directory
3. KUBECONFIG environment variable (currently not implemented)
4. ~/.kube/config file

Part of #595.

Signed-off-by: Mateusz Gozdek <mateusz@kinvolk.io>
After renaming --kubeconfig flag to --kubeconfig-file, we lost ability
to use kubeconfig file defined by KUBECONFIG environment variable for
installing components. This commit adds back this functionality and
improves the code of getKubeconfig() function a bit.

Closes #595

Signed-off-by: Mateusz Gozdek <mateusz@kinvolk.io>
Otherwise linter complains.

Signed-off-by: Mateusz Gozdek <mateusz@kinvolk.io>
So resulting code is much easier to understand.

Signed-off-by: Mateusz Gozdek <mateusz@kinvolk.io>
@iaguis iaguis force-pushed the invidian/rename-kubeconfig-flag branch from ad712a7 to 0687e1e Compare June 18, 2020 13:50
@iaguis
Copy link
Contributor

iaguis commented Jun 18, 2020

Addressed my review since @invidian is out.

@iaguis iaguis requested a review from ipochi June 18, 2020 13:51
cli/cmd/utils_internal_test.go Show resolved Hide resolved
cli/cmd/utils_internal_test.go Show resolved Hide resolved
cli/cmd/utils_internal_test.go Outdated Show resolved Hide resolved
@iaguis iaguis force-pushed the invidian/rename-kubeconfig-flag branch from 0687e1e to ab7638a Compare June 18, 2020 14:03
To make sure we do it right, as otherwise it might be destructive.

Signed-off-by: Mateusz Gozdek <mateusz@kinvolk.io>
@iaguis iaguis force-pushed the invidian/rename-kubeconfig-flag branch from ab7638a to 7470a24 Compare June 18, 2020 14:04
Copy link
Member Author

@invidian invidian left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@ipochi ipochi left a comment

Choose a reason for hiding this comment

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

Nice work @invidian @iaguis

lgtm

Copy link
Contributor

@iaguis iaguis left a comment

Choose a reason for hiding this comment

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

lgtm

@iaguis iaguis merged commit 0cbadba into master Jun 18, 2020
@iaguis iaguis deleted the invidian/rename-kubeconfig-flag branch June 18, 2020 14:39
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

KUBECONFIG env variable takes precedence over cluster configuration while selecting kubeconfig
3 participants