hybrid view of multiple topologies

[tomwilkie]

Lots* of people seem to run mixed containerise and non-containerise workloads, for instance we've seen at least three people run their load balancers outside of containers.

Right now it will show up as uncontained, but I've been think for a while a smarter hybrid view will be useful (ie show processes if they are not in a container, containers if they are. And visually differentiate.)

Thoughts?

[pidster]

I think a smart / hybrid view is a really good idea.

[rade]

visually differentiate

Shapes have taken care of that already.

+1 to the overall idea. In fact I wonder whether a container-only view is even necessary, i.e. perhaps we should simply replace the current container view with the hybrid view.

[2opremio]

Here's another user needing the hybrid view: https://weaveworks.slack.com/archives/scope-public/p1459362185000321

[2opremio]

Report from the user: https://weaveworks.slack.com/files/guang/F0WL9MS86/api_report.json.gz

[guang]

+1

[rade]

This doesn't just apply to processes and containers, but any topology.

We could go for a more radical solution: replace the individual topology views with a single hybrid view, and combine that with hierarchical navigation #719.

Such view would show you everything in existence, at the highest level of abstraction in which it has a representation, and the hierarchical navigation would allow you to "zoom in" and see a fragment of the space at a lower level. E.g. if we have just three processes, one of which is in a container and the others are in a container each, in a pod each, in the same service, then we'd show a container and a service, and hierarchical nav would allow the user to "expand" the service.

IMO this would make it easier for users to "get their bearings" and retain context while exploring their system.

There are a few topologies that do not fit into the above...

• topologies that are at the same level of abstraction but can share nodes from lower levels. IIRC this is true of some k8s topos, e.g. the same pod could be part of a service I guess we could just show all of them. See also https://github.com/weaveworks/scope/issues/1444#issuecomment-249333960
• topologies that represent abstraction along a different axes. e.g. 'Hosts', or represent completely different data, e.g. Weave Net peers. I reckon these are the views a user can select in this new world. (NB: the hosts topo should be the top level of an abstraction stack that has pods, containers and process topologies below it).
• pseudo topologies, like "Containers by Image Name". Perhaps these just become modes for viewing a particular layer, e.g. when I have "Containers by Image Name" selected, then instead of the hybrid view showing individual containers, it would show image pseudo nodes.

[ekimekim]

Here's a shot of the kube-system namespace on my minikube.

• kube-addon-manager is a pod with no parents.
• kubernetes-dashboard is a replica set without an associated deployment
• scope-app is a deployment
• scope-probe is a daemonset

Obviously, our big problem here is visual differentiation. Please note it's currently not possible without a more significant refactor to change what the node looks like (shape, sub-label, etc) depending on what view you're looking at - for example, we couldn't make deployments sub-label themselves deployment without also having that label show up in the Deployments tab. That may not matter so much if we remove the Deployments/Replicasets/Daemonsets views entirely.

So that's an option: Specify the higher levels type via a label (eg. instead of 1 pod, have daemonset of 1 pod), and rely on the stack vs single heptagon shape to distinguish between pods and other things.

[rade]

I do rather think different shapes would work best. Having text would be helpful in addition. I suspect we don't want three rows of labels though, so the "daemonset: 2 pods" might be the way to go. Or perhaps denote the type on mouseover only, since once users learn the shapes they won't need the text anymore, so it's just clutter.

[ekimekim]

note before we forget again: what behaviour should the table view have? since different node types have different columns.

[rade]

what behaviour should the table view have?

The obvious solution would be "union of all columns". Let's see how crowded that gets.

[rade]

It may be desirable to search/filter by "type" using the existing search/filter box. No need to do this initially.

[rade]

In #2552 we've swung back and forth between less and more hybrid.

There are problems with showing objects from different "levels" in the same view. To just take the example of including uncontrolled (aka "bare" pods) in the controller view from #2552...

• Where should links to uncontrolled pods go? The pod view or the controller view?
• When focusing on an uncontrolled pod in either view, should there be a way to switch to the other view while retaining focus?
• Pods have quite different (and a lot of) metadata, which makes the table mode unwieldy. How can we deal with that? Filtering by type would be one option.