The initial idea was to keep it separate since the unattached
links were also to be displayed distinctively from the metrics.
With the new design, unattached links are rendered in the same
list as metrics with attached links.
Therefore, we treat unattached metric links as an empty metric.
scope-app:
- Adds `-app.metrics-graph` cli flag for configuring the base url to
use for graph links; supports `:orgID` and `:query` placeholders
- Renders `metric_links` in node detail API response
scope-ui:
- Extends `<CloudFeature />` with option `alwaysShow` and adds
boolean `isCloud` property
- Links metric graphs in the ui's node details view for all k8s
toplogies; or displays placeholder graph if no metrics available
This guarantees that the output won't contain bare nodes containing
just an id and topology, as produced by ipToNode. Previously this was
ensured by calling convention, now it's ensured by construction.
When the scope-app restarts, it no longer has a
reference to the previous node set. Therefore,
the delta update adds *all* nodes but does not
remove legacy ones.
`reset==true` tells the frontend to start fresh.
Fixes#2708
The figure is inaccurate since it counts containers across all
hosts. Getting the count correct is non-trivial, so it's better to not
show the figure at all.
NB: the count still shows up on mouse-over of the link, but that is
defensible and not (very) confusing since the link represents the
image, not the image on a particular host, and it's the same count
that show up as the minor label in the container images view.
Fixes#2681.
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.
This map function isn't actually needed.
Children are only populated from mapping to parents during rendering,
so there's no pre-existing replicasets to map.
Simply having the Map2Parent function map pods to deployments has it do the right thing.
Use a special kind of selector renderer to elide replica sets from pod nodes
and directly reference deployment parents instead.
Do the inverse (replace replica sets with pods) during the mapping from pod to deployment.
Note we can no longer use renderParents since we're using a non-standard Selector
