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.
Some process nodes may not have a HostNodeID metadata, e.g. when an
endpoint references a pid that we know nothing about. When mapping
processes to containers, we therefore shouldn't rely on
HostNodeID. Instead we can obtain the hostID from the process node ID.
This has been broken for a while, possibly forever.
instead of a Map, since it's not really a map as it just updates the
given node.
This is more efficient and also matches what we do in similar
situations elsewhere, e.g. in ContainerWithImageNameRenderer and
ProcessWithContainerNameRenderer.
...when creating Uncontained pseudo nodes. Summarisation of
Uncontained/Umanaged only looks at the ID, which includes the
HostNodeID.
We adjust the promotion of Uncontained to Unmanaged, to operate on the
ID instead of (re)extracting the hostID from the HostNodeID
metadata. With that, nothing looks at the HostNodeID metadata of
Uncontained/Unmanaged nodes.
The ImageID is already the id of the node we are creation, and that's
what summarisation renders in the event we fail to join this node with
a node from the ContainerImage topology that has more metadata.
Nothing is looking at the ImageID metadata field.
This was building a set of all the image ids represented by the same
unversioned image. Well, it was doing that until I broke it with a
silly mistake in #1739 - instead of extracting the imageID from the
original node ID, it's extracting it from the updated ID, which is the
unversioned image. Even if it was working though, it's pointless
since nothing is looking at that info.
The container hostname is already the id of the node, and that's what
summarisation renders. Nothing looks at the docker.ContainerHostname
metadata of nodes in the ContainerHostname group topology.
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.
The 'create' function passed to addChild is only ever invoked when we
cannot find a matching process in the process topology. In these cases
the host and pid will be _all_ the info we are ever going to have,
both of which are incorporated in the id. Node summarisation renders
that as best it can; adding the PID as metadata does not make a
difference but for a line with that info in the detail panel, which
adds nothing since the PID is already included in the label.
The id and topology are enough to get some basic info for rendering.
This isn't just a fall-through for exceptional cases.
ContainerwithImageNameRenderer produces parent references using the
image name without version as the ID, and containers-by-image topology
uses that for grouping. By contrast, the container-image topology in
the report is keyed on docker image IDs.
We eliminate the custom parent renderer, which was a very partial
implementation MakeBasicNodeSummary.
We also ensure that parents are always rendered in the same, sensible
order. Previously the order was an alphabetic sort of the parent
topology IDs. Now lower level topologies come before higher level
topologies.
The node ID of group nodes is in fact the same value as we get from
looking up the metadata key contained in the group topology id. So
just use that since a) we always have it, and b) we save a LatestMap
lookup.
We fall back to image id when we cannot find a name. We extract the
image id from the node id rather than the docker.ImageID latest map
entry since that way we are guaranteed to get it.
The main change here is to to label the node with its pseudoID as the
last resort.
We also set the rank to the pseudoID instead of the full node id,
since including the "pseudo:" prefix is not conducive to good ranking.
The rest is just moving from 'if' to 'switch'.
We fall back to the truncated container id when we cannot find a
name. NB: this also happens when rendering a container as a parent.
We cope with the absence of an image name and/or host name.
We cope with the absence of the process name and/or container name,
and extract the hostID and pid from the node id rather than metadata
since that way we are guaranteed to get values for them.
This doesn't make any difference to the outcome - we were simply
setting the shape in the NodeSummary to "", which is what it starts
out as - but looks less weird in the code.
It's a dynamic type check of sorts.
In the process we stop abusing ParseNodeID for extracting the host,
which in turn allows us to clarify its purpose.
