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

[BUG] Clusters in error state can be reached but not clicked #10754

Open
lindhe opened this issue Apr 4, 2024 · 5 comments
Open

[BUG] Clusters in error state can be reached but not clicked #10754

lindhe opened this issue Apr 4, 2024 · 5 comments
Labels
kind/bug QA/dev-automation Issues that engineers have written automation around so QA doesn't have look at this status/backport-candidate
Milestone

Comments

@lindhe
Copy link

lindhe commented Apr 4, 2024

Rancher Server Setup

  • Rancher version: v2.8.2
  • Installation option (Docker install/Helm Chart): Helm chart (RKE2)
  • Proxy/Cert Details: n/a

Information about the Cluster

  • Kubernetes version: 1.27.10
  • Cluster Type (Local/Downstream): Local

User Information

  • What is the role of the user logged in? Admin

Describe the bug

We have some downstream clusters in the "Error" state. When they are in this state, they cannot be reached by clicking on them in Rancher's GUI. But if one happens to have a link to the cluster's page (e.g. https://rancher.example.com/dashboard/c/c-m-1id3bjdio/), then most functionality is still available. Either the cluster is not supposed to be reachable via Rancher at all, and the link should be disabled, or the link should be easy to find (e.g. by clicking on the cluster name like normal).

To Reproduce

Have at least one downstream cluster in the "Error" state. (I do not know how to reproduce that)

Result

The cluster can be reached via its link but not by clicking in the GUI.

Expected Result

Either, cluster access should be disabled completely (disabling the link too) or one should get to the cluster explorer by clicking the cluster's name (like with healthy clusters).

Screenshots

The red clusters cannot be reached by clicking on them, but if one have a link since before they became red then they can be browsed anyway:

image

@lindhe lindhe added the kind/bug label Apr 4, 2024
@rak-phillip
Copy link
Member

@lindhe thanks for raising this issue and helping to make Rancher better! We'll follow up on this issue to request more information, if needed, as we triage.

@gaktive I'm transferring this issue to the Dashboard repo for triage.

@rak-phillip rak-phillip transferred this issue from rancher/rancher Apr 4, 2024
@github-actions github-actions bot added [zube]: To Triage QA/dev-automation Issues that engineers have written automation around so QA doesn't have look at this labels Apr 4, 2024
@rak-phillip
Copy link
Member

This could be related to #10043, where we started taking into account the readiness of a cluster before disabling the link if there is an error1

@lindhe it sounds like the clusters in question might be in ready state but is now "faulty". Can you confirm that this is the case?

Footnotes

  1. https://github.com/rancher/dashboard/pull/10366/files#diff-d888082c4e23d876ed1154a65f0abf824000d685eda426eee3512d88318f7d2b

@gaktive gaktive added this to the v2.9.0 milestone Apr 4, 2024
@richard-cox
Copy link
Member

Given the UI depends on Rancher working correctly for many many things, think the best path is to redirect users away from anything with a cluster context to the home page if the cluster is not ready.

This might not be a 2.9.0 thing though.

@lindhe
Copy link
Author

lindhe commented Apr 5, 2024

@rak-phillip Thank you for the input! I'll try and check that issue and see if it seems to be the same state.

@lindhe
Copy link
Author

lindhe commented Apr 5, 2024

it sounds like the clusters in question might be in ready state but is now "faulty". Can you confirm that this is the case?

I'm not sure how to check for exactly what you are asking, but I think it looks like the cluster is in an error state and should not be considered ready:

image

image

@nwmac nwmac modified the milestones: v2.9.0, v2.9.next1 May 21, 2024
@gaktive gaktive modified the milestones: v2.9.next1, v2.10.0 Jul 2, 2024
@nwmac nwmac modified the milestones: v2.10.0, v2.11.0 Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug QA/dev-automation Issues that engineers have written automation around so QA doesn't have look at this status/backport-candidate
Projects
None yet
Development

No branches or pull requests

5 participants