Final list of shapes for controllers view, with rationale:
Heptagon for Deployment - same shape as Service, which typically have a corresponding Deployment
Triangle for CronJob - weird shape for weird thing
Pentagon for DaemonSet - because pentagons and daemon worship :P
Octagon for StatefulSet - last shape left
While we're there, adopt a consistent ordering for all places that shapes are listed
Order is least sides to most sides, with circle before polygons, and complex shapes (currently just Cloud) after.
On shape choices for topologies:
* Since the k8s logo is a heptagon, we want pods to be heptagons.
* Since triangle is 'a bit weird', we put it on the least-important type, replica sets.
* Pentagons look a little weirder than octogons (it's the lack of symmetry) so we put octogons on the most common (deployments)
By reducing the number of times we refer to every topology by name line by line,
we make it easier to add new topologies, reduce the risk of bugs where a topology is not listed,
and reduce the risk of the repeated lines getting out of sync with each other.
We introduce two new methods to assist this:
WalkPairedTopologies, a modified WalkTopologies that gives the called function
the same topology from two reports. This is used, for example, to implement Copy and Merge.
TopologyMap, which returns a map of all topologies by name. This is then used to implement all other methods.
This leaves only 4 instances of listing topologies:
In the consts at the top of the file, to give it a name
In the struct itself
In the constructor, where we need to set per-topology settings
In TopologyMap
The new probe will convert all node's LatestControls to Controls, so
the old app can consume them. Also, the new app will convert all
node's Controls to LatestControl, so it can consume the reports from
old probes.
Merge() is always returning a copy, so there is no need to Copy()
struct fields first before calling Merge() on them.
This reduces GC pressure (#1010) and helps overall app performance
(#1457).
Squash of:
* Include plugins in the report
* show plugin list in the UI
* moving metric and metadata templates into the probe reports
* update js for prime -> priority
* added retry to plugin handshake
* added iowait plugin
* review feedback
* plugin documentation
Squash of:
- use detailed.Summaries to render topology nodes
- ban merging nodes of different topologies (they should be mapped)
- need to prune parents when mapping node types
- render container images by id if they have no name
- remove separate render ids and prune parents in NewDerived*
- don't render metrics/metadata for groups of nodes
- fixing up tests
- removing pending unit tests (for mapping.go, for now)
- updating experimental dir for RenderableNode removal
* Added helper for installing scope on gcloud
* Added topologies Pods and Pods-by-Service
* Uses k8s.io/kubernetes/pkg/client/cache for the client
* Filter kube-system nodes by default
* Only show the k8s topologies if we've received a non-empty k8s report
Also, 1 packet may be counted in N topologies, so you can't rely on the
sum of all packet counts across topologies having any relation to the
sampling data.
This makes container image details show the containers (and processes) correctly.
Also:
- introduces a 'test' package, moved Diff function there.
- adds some tests for this new rendered view.
We only want to scope (i.e. prefix with hostID) those addresses that are
deemed loopback, to disambiguate them. Otherwise, we want to leave
addresses in unscoped form, so they can be matched, and links between
communicating nodes properly made.
So, we make the isLoopback check in MakeAddressID, and omit hostID if
the address isn't loopback. So far so good.
But this breaks topology rendering, as we were relying on extracting
hostID from adjacency node IDs, to populate origin hosts in the rendered
node output. So we need another way to get origin host from an arbitrary
node.
A survey revealed no reliable way to get that information from IDs in
their new form. However, we have access to node metadata, so this
changeset introduces the OriginHostTagger, which tags each node with its
origin host, via the foreign-key semantics we'll use going forward.
