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

Ignore clusters with invalid kubeconfig #1956

Merged
merged 16 commits into from Mar 1, 2021

Conversation

nevalla
Copy link
Contributor

@nevalla nevalla commented Jan 14, 2021

This PR will provide simplified version of #1453 to ignore clusters that have invalid/corrupted kubeconfig on cluster startup. With this PR those clusters are marked as dead and dead clusters are not enabled.

fixes #1316, fixes #1561

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
@nevalla nevalla added the bug Something isn't working label Jan 14, 2021
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
@jim-docker
Copy link
Contributor

If it's just invalid kubeconfig we're concerned with here can't we test it for validity before creating a cluster in the clusterStore? The Add cluster dialog could even filter out bad ones before building the context list (and show notification(s) indicating which contexts are bad). I never really liked the idea of carrying around dead clusters

@Nokel81
Copy link
Collaborator

Nokel81 commented Jan 14, 2021

There should be some sort of notification to the user, otherwise we will have bug reports stating that lens removes their clusters.

@nevalla
Copy link
Contributor Author

nevalla commented Jan 14, 2021

If it's just invalid kubeconfig we're concerned with here can't we test it for validity before creating a cluster in the clusterStore? The Add cluster dialog could even filter out bad ones before building the context list (and show notification(s) indicating which contexts are bad). I never really liked the idea of carrying around dead clusters

We have some validation when adding a cluster and this PR will improve that even. This "dead cluster" issue occurs when some process outside of lens app is modifying kubeconfig file for the cluster that is already added to Lens.

@nevalla
Copy link
Contributor Author

nevalla commented Jan 14, 2021

There should be some sort of notification to the user, otherwise we will have bug reports stating that lens removes their clusters.

Yes, that would be nice. Let me see what I can do for it.

@nevalla
Copy link
Contributor Author

nevalla commented Jan 14, 2021

One option could be to send notifications from all dead clusters on start up? Is it possible to have some custom action on notification, for example remove the cluster completely?

@Nokel81
Copy link
Collaborator

Nokel81 commented Jan 14, 2021

One option could be to send notifications from all dead clusters on start up? Is it possible to have some custom action on notification, for example remove the cluster completely?

Yeah that is a good idea. "Ignore" and "Remove" maybe?

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
@nevalla nevalla requested a review from a team January 15, 2021 09:45
@nevalla
Copy link
Contributor Author

nevalla commented Jan 15, 2021

Notifications would benefit from #1941, so I propose that should be done in a future PR.

@nevalla
Copy link
Contributor Author

nevalla commented Jan 15, 2021

Added unit tests for kubeconfig validation. I think this is now ready for the review, so please take a look.

* Validates Context, User and Cluster sructs in given kubeconfig. Additionally this will validate
* the command passed to the exec substructure.
*/
export function validateKubeConfig (config: KubeConfig, contextName: string, validationOpts?: { validateCluster?: boolean, validateUser?: boolean, validateExec?: boolean}) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you extract the this out to ValidationOptions?

Copy link
Collaborator

Choose a reason for hiding this comment

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

And provided a default {} for validationOpts

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

*
* @observable
*/
@observable isDead = false;
Copy link
Collaborator

Choose a reason for hiding this comment

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

This doesn't need to be observable since it is only set in the constructor.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

changed as public property now.

Comment on lines 172 to 177
/**
* Is cluster marked as dead, for example due the invalid kubeconfig
*
* @observable
*/
@observable isDead = false;
Copy link
Collaborator

Choose a reason for hiding this comment

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

And as I mentioned in my previous PR, I really think that adding this field is conflating what a cluster is.

@matti
Copy link

matti commented Jan 21, 2021

ping - my lens corrupts daily and I need to remove applicationsupport/lens

@jakolehm jakolehm added this to the 4.0.9 milestone Jan 21, 2021
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
@nevalla nevalla requested a review from a team January 22, 2021 13:09
Comment on lines 160 to 161
* Validates Context, User and Cluster sructs in given kubeconfig. Additionally this will validate
* the command passed to the exec substructure.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* Validates Context, User and Cluster sructs in given kubeconfig. Additionally this will validate
* the command passed to the exec substructure.
* Checks if `config` has valid `Context`, `User`, `Cluster`, and `exec` fields (if present when required)

@@ -76,6 +76,7 @@ export class Cluster implements ClusterModel, ClusterState {
* If extension sets this it needs to also mark cluster as enabled on activate (or when added to a store)
*/
public ownerRef: string;
public isDead = false;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I still don't think that a cluster should be created at all if the kube config is invalid or non-existant.

jakolehm
jakolehm previously approved these changes Jan 29, 2021
@jakolehm jakolehm requested a review from a team February 4, 2021 18:17
@jakolehm jakolehm added this to the 4.1.4 milestone Feb 24, 2021
@nevalla
Copy link
Contributor Author

nevalla commented Feb 25, 2021

I've created separate PR (#2233) to display a notification when cluster with invalid kubeconfig is detected.

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
@nevalla nevalla dismissed stale reviews from aleksfront and jakolehm via f676429 February 25, 2021 14:21
@Nokel81
Copy link
Collaborator

Nokel81 commented Feb 25, 2021

That notification looks good, but the trigger is still wrong IMO. It should be triggered from ClusterStore when a constructor fails. And when it fails it shouldn't be treated as an "alive" cluster (with its icon and such).

@nevalla
Copy link
Contributor Author

nevalla commented Feb 25, 2021

That notification looks good, but the trigger is still wrong IMO. It should be triggered from ClusterStore when a constructor fails. And when it fails it shouldn't be treated as an "alive" cluster (with its icon and such).

It's not "alive" cluster, Lens already ignores clusters that are not enabled.

@Nokel81
Copy link
Collaborator

Nokel81 commented Feb 25, 2021

But why add it to the list then in the first place?

@nevalla
Copy link
Contributor Author

nevalla commented Feb 25, 2021

But why add it to the list then in the first place?

If it's not in the list, it will get lost when persisting the data to cluster store.

@Nokel81
Copy link
Collaborator

Nokel81 commented Feb 25, 2021

Then that implies that there should be another field for kubeconfigs that are no longer valid (since we validate them on the add step).

@nevalla
Copy link
Contributor Author

nevalla commented Feb 25, 2021

IMHO this is still improvement to the current situation where Lens app is crashing if there are corrupted kubeconfigs associated. What is also good with this PR, it's not changing existing functionality too much.

@lensapp lensapp deleted a comment Feb 26, 2021
@Nokel81
Copy link
Collaborator

Nokel81 commented Feb 26, 2021

I agree that it is an improvement (but then again so was my PR (which I will no close)). But given that the imo better solution isn't that much extra work. And doesn't future complicate an already very complicated class (namely Cluster). I think it is worth it do it that way the first time around.

Yes it adds another field, that rarely if ever gets populated, to ClusterStore but I still think that from a design perspective we shouldn't be having these sorts of try {} catch {} blocks within a constructor.

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
@nevalla
Copy link
Contributor Author

nevalla commented Mar 1, 2021

I've now removed isDead property so extensions API won't have any changes by this change. Cluster.apiUrl is now checked instead when setting cluster as enabled.

jakolehm
jakolehm previously approved these changes Mar 1, 2021
* Display warning notification if invalid kubeconfig detected

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
Copy link
Collaborator

@Nokel81 Nokel81 left a comment

Choose a reason for hiding this comment

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

This is definitely better though I still would like to see in the future removing that try { ... } catch { ... } from the constructor and have these clusters be part of a separate list to keep the conceptual size of what a Cluster instance "is" as small as necessary.

@jakolehm jakolehm merged commit 4f74b9a into master Mar 1, 2021
@jakolehm jakolehm deleted the fix/ignore-clusters-with-corrupted-kubeconfig branch March 1, 2021 15:30
jakolehm pushed a commit that referenced this pull request Mar 3, 2021
* Ignore clusters with invalid kubeconfig

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Improve error message

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Mark cluster as dead if kubeconfig loading fails

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Fix tests

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Validate cluster object in kubeconfig when constructing cluster

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Add unit tests for validateKubeConfig

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Refactor validateKubeconfig unit tests

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Extract ValidationOpts type

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Add default value to validationOpts param

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Change isDead to property

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Fix lint issues

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Add missing new line

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Update validateKubeConfig in-code documentation

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Remove isDead property

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>

* Display warning notification if invalid kubeconfig detected (#2233)

* Display warning notification if invalid kubeconfig detected

Signed-off-by: Lauri Nevala <lauri.nevala@gmail.com>
@jakolehm jakolehm mentioned this pull request Mar 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
6 participants