We replace the existing data structure with a simpler one that
only specifies how to get the parent label, which is the only
part of the Parent struct that can't be generated from the node info alone.
Future work: Standardize this concept of a label and put it in the topology instead.
Though that already exists...so just use it?
The default sets the node label to the node ID.
This is likely to not look very good, but the intent is that it creates an obvious problem,
ie. that the node ID is being used as the label, rather than a silent omission or more subtle problem.
Possible future work:
* For single-component IDs, extract the component automatically and use that instead.
* Instead of functions, in simple cases just have a LUT by topology with common behaviours like
'stack = true or false', 'label = this key in node.Latest'
The latter opens up to eventually moving this info inside the report itself ala topology templates,
or at least centralizing it in the source.
Currently, if a topology does not have any specific info in nodeSummariesByID,
any children of the node that belong to that topology will be silently omitted.
This change adds a default behaviour for such topologies, with no special columns
but at least it is displayed at all.
Unlisted topologies are displayed after all listed ones, in arbitrary order.
Note that completely bogus or other special cases (eg. topology = Pseudo) still will not
be displayed as report.Topology() will fail.
This gives us a single source of truth in a variety of situations where we want to
know what view to direct a user to in order to 'open' a particular node.
I wanted to put this in app/api_topologies where the views are defined, but that creates
a circular import.
This is important for two reasons:
* It prevents nasty false-equality bugs when two different services from different ECS clusters
are present in the same report
* It allows us to retrieve the cluster and service name - all the info we need to look up the service -
using only the node ID. This matters, for example, when trying to handle a control request.
- Rename DataType -> Datatype for consisitency
- Remove Datatype from connection.metadata
- Change UI to read dataType from connection.columns rather than from
connection.metadata (col header rather than "cell")
in the details panel, instead of showing connections to/from the
internet as "TheInternet <port>", we now show "<dns-name>(<ip_addr>)
<port>" (or just "<ip_addr> <port>" if we don't have a dns name).
Fixes#1713.
Instead of including the localEndpointID in the key, use the
address, so the port is excluded. That way we don't end up with multiple
rows for inbound connections from the same internet address.
We also augment the address with the DNS info here, which saves us from
having to look it up later on.
Fixes#1867
This preserves the existing behaviour of showing count=0 as a plural
rather than empty. However, I rather suspect we cannot actually
encounter that case in the current code.
In the "no count found" case we now *set* the base.LabelMinor to empty
instead of leaving it alone. This is ok since it is empty to begin with.
There were two problems:
- the renderer was looking for reverse names on the destination
- the probe was not annotating source nodes with reverse-resolved names
Fixes#1847
Mike Lang
Mike LangandGitHub
Filip Barl
Jonathan Lange
Alfonso AcostaandMike Lang
Alfonso AcostaandGitHub
Simon Howe
Lorenzo Manacorda
Matthias Radestock