-
Notifications
You must be signed in to change notification settings - Fork 515
Multi-cluster Istio components status #8170
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
Conversation
0f5e8bb
to
231ddb7
Compare
business/istio_status.go
Outdated
// if no control plane and no any other control plane which manages external | ||
if len(istiodStatus) == 0 && !managesExternal { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this covers the case where a controlplane may be managing an external cluster but it's not the current cluster. e.g.
You have 3 clusters: A, B, C. A manages B but nothing manages C.
I don't think you need to look at ManagesExternal
. You just need to know if there's a controlplane managing this cluster or not e.g. if cluster not in controlPlanes.managedClusters
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also not sure if this is always an error. You could have an "observability" cluster for instance where the observability components live separate from any istio components.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A problem with showing an error when the istiod is not found is that a user may not have access to the cluster where the istiod lives so this would show an error even though the istiod does exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have somewhere documented all those combinations? or it is only here? https://istio.io/latest/docs/setup/install/multicluster/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have changed the logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have somewhere documented all those combinations? or it is only here? https://istio.io/latest/docs/setup/install/multicluster/
It's just there but there but you can also combine some of those e.g. external control plane + primary-remote.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code looks good. Any new multi-cluster cypress tests that should be added for this to test the new masthead functionality?
there are existing multicluster tests which are passing now, when all components are running fine, can be added a new ones to check that all cluster are in tooltip |
Since we're adding new functionality, it'd be good to also add new tests to cover it. |
…tip on remote cluster in overview card, midifying tests
Added component unhealthy test
Then user sees a tooltip with text "west" | ||
Then user does not see any "Not" in the tooltip | ||
Then user does not see any "Unreachable" in the tooltip | ||
Then user hovers out the cluster icon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this last assertion testing? Seems like it performs an action but does no assertions afterward?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was like a cleanup, to close the tooltip, will move it to separate after
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed
@multi-cluster | ||
@component-health | ||
Scenario: Istio components unhealthy | ||
When user scales to "0" the "prometheus" in namespace "istio-system" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A faster way to do this is to just intercept and mock the status response to change one of them to unhealthy. I'm worried that actually scaling prom up/down could affect other tests after this one that rely on metrics data like graph tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by mocking, we could not really test all those changes in the backend, it will be only UI functionality check,
but I agree that up/down of prometheus can cause some flake tests in backend, maybe I can up/down another component which is less sensitive, for instance 'grafana'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nrfox thanks for the review, made 'grafana' up/down scale instead of 'prometheus', and '@component-health-upscale' after operaton upscales it.
When user hovers over the cluster icon | ||
Then user does not see any "Not" in the tooltip | ||
Then user does not see any "Unreachable" in the tooltip | ||
Then user hovers out the cluster icon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question here about this action at the end. Seems like it's not being used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed the code and tested locally, everything looks fine for me, good job @hhovsepy 🙂
However, clarifying that this is not related to this PR, when I forced Grafana to be unreachable to trigger a warning, the Mesh page did not show this warning. Instead, it displayed a valid connection.
Does it happen the same to you?
Thanks for the review and cooperation @ferhoyos , yes this happens to me as well. Probably we need another issue logged. |
Describe the change
Kiali Masthead which shows Home cluster name and the components statuses are merged now.



It shows single icon with tooltip:
Added multicluster support of components statuses:
Always showing sorted the worst status cluster the first.
From Control plane card removed "Remote Cluster" label as all cluster's are listed in Masthead.
Steps to test the PR
Test for primary-remote and multy-primary cases.
Regression test for single cluster case.
Automation testing
Modified the cypress and unit tests.
Issue reference
#7724