don't report on replicasets from probe

[rade]

In #2661 we removed replicasets from the display, instead adding deployments as direct parents of pods. Once we are sure that is the right way to go we should in fact remove replicasets from the probes, performing the mapping to deployments there, and convert old reports to the new format in report.Upgrade() for backward compatibility.

That should improve performance in several ways:

• reduced report size, and hence probe report writing, app report reading, and app report storage performance - replicasets constitute a monotonically growing data set, since during normal operation the replicasets of old deployment generations are never removed
• improved rendering performance since we no longer need to do the mapping there

[rade]

I've looked at a recent set of reports from one of our clusters. These contain nearly 2500 replicasets. And they do get reported by every node. That means that overall they are the most numerous report entity.

[rade]

remove replicasets from the probes, performing the mapping to deployments there

It would be lovely if the probes were able to do that w/o retrieving all replicasets, which is what they do now.

and convert old reports to the new format in report.Upgrade() for backward compatibility.

We can probably leave that for later. By my reading of selectPodsWithDeployments.Render(), it will Just Work. OTOH, moving that code into Report.Upgrade() shouldn't be hard either.

[bboreham]

btw report.Upgrade() currently does a copy on every call, which is expensive in the common case that it doesn't need upgrading. Can we have a version number or something like that so we can easily tell which is which?

[rade]

Can we have a version number or something like that so we can easily tell which is which?

File an issue.

[rade]

report.Upgrade() currently does a copy on every call, which is expensive in the common case that it doesn't need upgrading

Filed #2959.