'Unmanaged/Uncontained' nodes are not useful

[rade]

When projecting nodes from lower-level into higher-level topologies, we create 'Unmanaged/Uncontained' pseudo nodes when the lower-level node has no representation in the higher-level topology. Examples:

• in the controller topology, when a pod was not created by a controller
• in the pod topology, when a container does not belong to a pod
• in the container topology, when a process does not belong to a container

However, we create one 'Unmanaged/Uncontained' pseudo node per host on which the unmanaged/uncontained node resides. This is not at all useful.

What would be useful is to simply show the individual nodes. E.g. in the controller topology we would show individual pods that were not created by a controller.

This can of course become overwhelming, but that's why we have filters for 'Unmanaged/Uncontained', which are enabled by default.

[rade]

This gets us some way towards #552.

[bboreham]

we create one 'Unmanaged/Uncontained' pseudo node per host on which the unmanaged/uncontained node resides

I came here to complain about "Unmanaged" on the Controllers view; I am seeing three Unmanaged nodes for three hosts (Sock Shop demo) but the things under them do not divide along host lines. For instance, one of them has all three kube-proxy containers.

[rade]

one of them has all three kube-proxy containers.

That's because of #2931.

[rade]

simply show the individual nodes.

I've had a few attempted at implementing this and encountered a complications in a few areas:

Filtering

Topologies have filters, and we have default filters in place for most, to reduce clutter and only show what's likely most useful, e.g. we exclude unconnected processes and system containers. What should happen to these filters when showing nodes from a topology in the view of a different topology?

The options are:

1. don't apply any filters - easy to understand and implement, but can cause significant clutter
2. apply default filters - easy to understand, somewhat more difficult to implement, no clutter but also no way to see everything, which kinda defeats one of the objectives of these combined views
3. apply the filters currently selected in the promoted topology's view - gives users control over what to show, but the control may not be obvious and changing the filters requires switching views. Also fairly complex to implement
4. show the filters for both topologies - provides control over what to show, but will result in a somewhat unwieldy filter area, especially since the descriptions of the filters need to be disambiguated to make clear what nodes they apply to. Moderately difficult to implement.

Table View

How should the table view work, given that nodes from different topologies have different metadata?

The options are:

1. show the union of columns. Thus there is a single few, and single sort order and search. Downsides... This can result in a lot of columns, which in turn means many may be too narrow to see full details. And it may not be immediately obvious which topology a particular row belongs to. Also, some metadata fields with the same meaning have different names in different topologies. So, for example, we'd end up with two CPU and Memory usage columns when showing processes and containers, since the metrics are named differently.

2. have separate tables for each topology. This uses space effectively, and makes it clear what nodes belong to what topology. No unified sorting though. And complicated to implement.