After dropping extra metadata in the rest of this PR, our usage of
joinResults.add* only ever ends creating minimal nodes, from just an
id and topology. Hence joinResults.add* can be invoked with simply an
id and topology instead of a generic node creation function.
The HostNodeID is already the id of host nodes (as the name suggests),
and that's what summarisation renders. Nothing looks at the HostNodeID
metadata of host nodes.
Since we seed the joinResult with the nodes from the topology we are
mapping to, we know the 'create' function is only called when there is
no node with the specified id.
This neatly makes the 'create' function only do what it says,
i.e. return _new_ nodes.
This eliminates the awkward distinction between ProcessRenderer and
ColorConnectedProcessRenderer.
It also ensures that processes resulting from direct rendering of the
process topology (/api/topology/processes is invoking
ProcessWithContainerNameRenderer and /api/topology/processes-by-name
is invoking ProcessNameRenderer) are colored and hence summarising
them correctly sets the 'linkable' property. This was the behaviour
prior to the revamping of the rendering pipeline. However, it doesn't
actually make a practical difference since process detail panels only
show other processes as connection endpoints, and these are always
marked linkable anyway.
This is preparatory to future refactorings: all existing calls are to
Endpoints which have no children and where we don't want a Counter.
We make addChildAndChildren an obvious extension of addChild even
though it adds a dead code path (we never call addChildAndChildren
with an endpoint).
This allows us to avoid creating a host of 'IP' type Nodes then
discarding them after matching; instead we match directly and create
just the result we want.
and add a comment indicating non-memoisation of other, not shared
top-level renderers.
This memoisation is effective when the browser requests multiple
topologies for the same report.
The same container image may be in use on multiple hosts. The
latest-map HostNodeID of a node in the ContainerImage topology is
therefore meaningless - it gets set to whatever host reported that
image last in the time window covered by the report. Hence using it as
a basis for mapping to hosts, as we did, a) fails to associate images
with all the right hosts (hence they are missing from the host details
panel), and b) causes that association to change semi-randomly (hence
the list in the details panel is unstable).
By contrast, the host topology parents of container image nodes is the
complete set of all hosts the image is used on. So making that the
basis for mapping fixes the problem.
The same technique - mapping based on host parents rather than
latest-map HostNodeID - also works for the other nodes we are mapping:
processes, containers and pods. So we might as well use it there
too. That's also what Map2Parent does in other topology renderers.
Fixes#2629.
ProcessRenderer was coloring connected nodes because we need that info
for rendering details panels. However, the main process topology view
renderers depending on ProcessRenderer were also doing coloring
themselves. For the 'processes' topology that was literally
duplicating work. For the 'processes-by-name' topology that was
throwing away the process coloring, and then coloring at the name
level.
Solution: remove the coloring from the ProcessRenderer, thus
eliminating the duplicate/thrown-away work, and introduce a
ColorConnectedProcessRenderer which is only used in places that
populate details panels.
* Add filters for pseudo nodes.
- Don't filter the internet node as a pseudo node.
- Rename pseudo filter to unmanaged/uncontained.
- Review feedback
- Move the FilterFoo funcs into the tests
- Drop the 'nodes' from filter labels.
* Fix experimental
