• Evaluate the CI job results if the kube-burner feature is aggregating value to the final artifacts.

ACCEPTANCE CRITERIA:

• Tested v0.6-alpha* release with kube-burner must no increase much time in the final job execution
• Artifacts must not increase much (>5MiB) in size
• The data collected have proofed the minimum value. Examples:
  • standard kube-burner profiles is collecting similar metrics used when evaluating integrated providers of performance (non-scale)
  • metrics isn't duplicated with existing metrics collector - priority for kube-burner metrics if we need to decide/prevent duplicated data collected
  • we can provide a minimum guide of what to extract from the kube-burner results along side the metrics/target and expected values, such as:
    • Control Plane: Node-density light: p99 podReady latency should be <=3s
    • Control Plane: Node-density heavy: p99 podReady latency should be <=41s
    • Control Plane: Node-density CNI: p99 podReady latency should be <=5s
    • Cluster-density-v2:
      • Pod ready latency: p99 pod ready latency of all members: <target value TBD in baseline topology>
      • Etcd fsync latency: Avg 99th fsync latency of all members: <target value TBD in baseline topology>
      • Etcd commit latency: Avg 99th commit of all members: <target value TBD in baseline topology>
      • Etcd round trip latency: Avg P99 round trip of all members: <target value TBD in baseline topology>
      • Read only API request P99 latency - resource scoped: Avg P99 latency : <target value TBD in baseline topology>
      • Read only API request P99 latency - namespace scoped: Avg P99 latency : <target value TBD in baseline topology>
      • Mutating API request P99 latency - namespace scoped: Avg P99 latency : <target value TBD in baseline topology>

Note: It would be nice to evaluate the effort of extracting those data from results, if the steps would increase, a command can be introduced to automatically extract and insert in the final report (expanding by a new story).

Goals:

• Review if the jobs is not taking long to execute
• Review if the data collected from kube-burner is aggregating information to have an overview of baseline performance of kube-api, etcd, and other metrics collected by the standard kube-burner profiles used to ensure readiness in OCP releases
• Review if the stable v0.6 will deliver kube-burner as opt-in or opt-out.
  • If we'll opt-out by default, a flag must be added to enable it when running the workflow ('run' command)