Pod startup time phases are inaccurate in longer tests.

[wojtek-t]

gatherScheduleTimes:
https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/measurement/common/slos/pod_startup_latency.go#L268
is currently listing events at the end of the test.

Given that events by default have 1h TTL, for measurements across longer periods it just returns incomplete results. Given that we don't 100% accuracy, we should switch to a mechanism that is similar to the one that slo-monitor is using (added in #1477 ).

[sourikghosh]

/assign

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[wojtek-t]

/remove-lifecycle stale

[harshanarayana]

@wojtek-t Is someone working on this still or can I take a stab at this ?

[harshanarayana]

/assign