Switch cluster view is confusing for federated users

[kbrwn]

What problem are you trying to solve? Switch cluster view displays info about a single cluster. This under represents the data available for federated kubecost deployments and is confusing to endusers. (ie users think they are only looking at data for the cluster displayed)

Describe the solution you'd like

• option to disable switch view
• option to customize more than just cluster name
• indication on switch view that federated / multi-cluster data is available

gz#1344

(related to Zendesk ticket #1344)

[dwbrown2]

@nikovacevic and I have discussed this being "Switch context" or something related to be more clear.

[nikovacevic]

Love this idea. Perhaps just a name change, like "Switch context" gets us there, but I think we'll want to enrich that with more information relating to federated clusters; e.g. how many clusters, what are their names, providers, etc.

[nealormsbee]

Adding this to my Coda for next week

[nealormsbee]

Submitted a draft POC here: https://github.com/kubecost/cost-analyzer-frontend/pull/462

Main idea is to prevent users from having to do work to set up and define a 'context' if they don't want to. They can still just add Kubecost cluster urls, but to help reduce confusion on multicluster setups, the UI would refer to these as "Kubecost Contexts", which is really what they are. Each cluster added is running an instance of Kubecost, which may be monitoring one or several clusters.

Send me your thoughts! If this seems directionally correct, I can do the same for non-react pages, the index page, etc.

[nealormsbee]

We've mostly talked about this in terms of the terminology (cluster vs. context) being confusing for federated users.

Another case that I imagine is common for federated users is that they don't have multiple contexts at all -- they want to use a single Kubecost context backed by a Thanos (or other) DB with all of their cluster data. At that point, the terms aren't the problem. It's the idea of switching views at all that's confusing.

I'm not rushing to remove the Switch Cluster/Context button from the nav, but I can see how an index page with "List of Contexts!" is an annoying place to start each use when you will only ever have one context (that's why @valdisrigdon upvoted this, I believe).

What if we had a setting to make / redirect to /overview.html ? Or we could do it automatically: If the FE detects that a KC is backed by Thanos, and only has one context configured, go straight to Overview?

[nealormsbee]

If I recall correctly, we've even talked previously about remove this view altogether, making Overview the landing page, and then leaving the nav bar's Switch Cluster option as the sole mode of switching.

[valdisrigdon]

+1 to the overview redirect if we are Thanos backed -- and if that's happening, the button near the bottom that says "switch cluster" could be hidden too.

[teevans]

What if we had a setting to make / redirect to /overview.html ? Or we could do it automatically: If the FE detects that a KC is backed by Thanos, and only has one context configured, go straight to Overview?

@nealormsbee - Could I bother you to take point on doing this for 1.94?

I think that intelligence of knowing whether or not we need to show the root selector would be a much better UX.

[teevans]

Assigning to @jjarrett21

[dwbrown2]

@teevans @jjarrett21 let me know if I can help here. one thing to point out is that changes to overview may impact how we execute on this...

[teevans]

So here's my spitballed thoughts from a product perspective.

I think one direction is to introduce a new noun into the system.

I would argue we introduce the word Context into the environment. Context is defined as which Kubecost API are we talking to? For Business and below, this is a single cluster at a time. So switching the context is in turn switching which single cluster we're talking to. I still think this provides value at times, though rare.

Enterprise is the only tier that "allows" a federated environment backed by Thanos. So for any environment like that I would argue that the Context is a single set of Federated clusters. SO, a user could have multiple contexts that each have their own set of federated clusters.

That direction allows us to handle all license tiers in a fairly flexible way, and gives us a decent definition when talking to customers.

The other direction, would be to remove this cluster switching feature all together, and therefore provide no context. In this model, federated clusters are singularly managed with no confusion of "which cluster am I managing"

For those without federated clusters, it would then be on the customer to have all of their different clusters bookmarked accordingly.

Personally, I would vote for removing the cluster switcher all together. Less code, less hassle from an engineering point. From a sales point we have a clear concise feature addition in the eyes of the user to manage multiple clusters at once. And from a customer perspective, there isn't this vague overarching context that adds a rarely used complexity. Would love to open this up for discussion here.

[jjarrett21]

Definitely want to get familiar with the current state of this before having a solid opinion on the matter, but from a high level I think that being able to manage all clusters at once is a lot more user friendly than managing switching clusters.

[mbolt35]

I still feel like this idea bleeds over into all areas of the product and we should have a group discussion to nail this down completely. The opening "Select Cluster" is the misleading terminology. I think this is what we're calling "Context" but it is truly a "Project" - the structure itself represents a single cluster or group of clusters. While we can't really do this today, I feel our data modeling and federation plans push us towards the direction of "Project Creation" where we allow a "New Project" modals that allow you to select specific clusters to include, etc... Again, not there yet, but I think we want to be open to this approach.

The second part of this happens when you select a Project/Context, what does that actually mean? Today, it means that the handful of features that only work for the local install (omitting other cluster's data)... ie: Health, Some Savings features, and a few others...

A good litmus for determining this is go to a page for a feature: Does it have a drop down selection for Cluster? If not, it is currently only showing you data for the local cluster.

This is why it's confusing, because our main pages show you all multi-cluster data, allow you to filter clusters, include all of them, etc... However, there are a few features that still use local-only data. I have a proposal that would move the needle here in a big way by simply giving the frontend access to that "local cluster" data in a multi-cluster context.

The Full Proposal: https://github.com/kubecost/kubecost-cost-model/wiki/Hosted-Multi-Cluster Applicable to Frontend: https://github.com/kubecost/kubecost-cost-model/wiki/Hosted-Multi-Cluster#api-usage

While the title notes "Hosted Multicluster", this is very applicable for the on-prem install as well, especially for federated users.