These can be long-running operations, and if the client retries we get
the cancelled one running in parallel with the retry, slowing both down
and making it likely the next one will time out too.
This dependency makes it harder to see the structure of the program,
and sometimes complicates compilation.
Mostly just changing the source of strings that are already exported
from the report package. A few new strings have to be moved there,
plus the function `IsPauseImageName()`.
This covers:
- Implementation of the job resource in probe
- Reporter changes for the job
- Add Describe Control to the job
- Pass job object to the kube controller renderer
ToDo:
- Need to decide the shape for the Job.
Signed-off-by: Satyam Zode <satyamzode@gmail.com>
* Pass Go context down to Renderers
This is useful for cancellation or tracing.
* Add tracing spans to app
Also log things like number of nodes in Map, total number of reports.
This will:
- Add StorageClass resource. Storage classes are mentioned
in the PVC spec. We're using storage class name from PVC spec to
add adjacency to the PVC node.
- Add square sheet shape for StorageClass.
- Add storage filter in the PODS topology.
Storage Filter will allow user to see distinct view of
stateful applications.
- Add visually distinct edge to show storage adjacency.
Signed-off-by: Satyam Zode <satyam.zode@openebs.io>
This isn't quite as neat as we'd want to make it, because two of the
three call sites still require a closure, but it's still an
improvement.
Note that every instance of MapEndpoints only ever maps to one
topology, which, furthermore, is a core report topology. Hence we can
just parameterise MapEndpoints with that topology, and then the map
functions can return just the node ids.
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.
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.
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.
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
* Maps metrics if there is a single pod in the controller, as per all other views.
* Also added heavy commenting on the increasingly-complex render chain
The existing technique of "reducing" the two rendered graphs for daemonsets and deployments
had a glaring issue that no connections would ever be made between nodes of different types,
since that information would've been discarded earlier in the process.
It also makes it hard to identify "parentless" pods.
This commit extends the Map2Parent function, teaching it:
* To check multiple topologies for parents
* To pass through nodes with no parents found without modification
Since we already had two 'modes' for what to do with nodes without parents,
and it would've been clunky to try to encode the third option into the existing PseudoNodeID
arg in some way, we instead split it into two args, with the first being an enum specifying
either the old pseudo node behaviour, the old drop behaviour, or the new keep behaviour.
We then use the new Map2Parent to map pods to:
* A replica set, if it has one
* A daemonset, if it has one
* Itself, if neither of the above
and then map again from the results to any deployment, leaving as-is any nodes that
don't map to a deployment. Hence we are left with:
* Deployments
* Daemonsets
* Replica sets, but only if they map to no deployment
* Pods, but only if they map to none of the above
and connections between all these will be calculated correctly.
