Skip to content

Add --report CLI option#300

Merged
openshift-merge-bot[bot] merged 1 commit intocloud-bulldozer:mainfrom
mohit-sheth:summary-analysis
Apr 9, 2026
Merged

Add --report CLI option#300
openshift-merge-bot[bot] merged 1 commit intocloud-bulldozer:mainfrom
mohit-sheth:summary-analysis

Conversation

@mohit-sheth
Copy link
Copy Markdown
Collaborator

@mohit-sheth mohit-sheth commented Mar 2, 2026

Type of change

  • Refactor
  • New feature
  • Bug fix
  • Optimization
  • Documentation Update

Description

  • Adds a new --report CLI option that supports two modes:
    • Standalone mode (--report file1.json,file2.json): reads pre-existing orion JSON output files and generates a consolidated regression report without running any analysis
    • Integrated mode (--report as a flag): appends a summary report after normal orion analysis
    • Introduces orion/report.py module with functions to parse orion JSON output, extract changepoints with regressed metrics, and render a formatted report with per-workload pass/regression/skip status, metric tables, and PR relevance sorting

Prow PR: Add deferred Orion summary report step for consolidated regression reporting openshift/release#75575

@vishnuchalla
Copy link
Copy Markdown
Collaborator

/hold

@chentex
Copy link
Copy Markdown
Member

chentex commented Mar 5, 2026

I like the stand alone option to run against json result files of Orion, allows quicker analysis to those files.

But I do not think adding this as an integrated part of the orion run is necessary, we already have all that data there and we can arrange the output to include it. Currently when passing --sippy-pr-search, we get extra details, like

Regression(s) found :
--------------------------------------------------
Previous Version:    4.22.0-0.nightly-2026-02-23-123227
Bad Version:         4.22.0-0.nightly-2026-02-23-223725
PR diff:
- https://github.com/openshift/api/pull/2637
- https://github.com/openshift-assisted/assisted-installer-ui/pull/3409
- https://github.com/openshift-assisted/assisted-installer-ui/pull/3410
- https://github.com/openshift/assisted-installer-agent/pull/1351
- https://github.com/openshift/assisted-installer/pull/2027
- https://github.com/openshift/assisted-service/pull/9915
- https://github.com/openshift/assisted-service/pull/9917
- https://github.com/openshift/cluster-api-provider-aws/pull/584
- https://github.com/openshift/cluster-api-provider-azure/pull/357
- https://github.com/openshift/cluster-api-provider-gcp/pull/258
- https://github.com/openshift/cluster-api-provider-ibmcloud/pull/150
- https://github.com/openshift/cluster-api-provider-metal3/pull/58
- https://github.com/openshift/cluster-api-provider-metal3/pull/64
- https://github.com/openshift/hypershift/pull/7436
- https://github.com/openshift/hypershift/pull/7723
- https://github.com/openshift/machine-config-operator/pull/5661
- https://github.com/openshift/operator-framework-operator-controller/pull/641
- https://github.com/openshift/ovn-kubernetes/pull/2982
--------------------------------------------------

If we work on improving this, the integrated report is not necessary.

I opened #307 this PR that already improves on the output of the table, we can use it to improve the summary output also.

@mohit-sheth
Copy link
Copy Markdown
Collaborator Author

@chentex Thanks for reviewing this
I think whatt users really want is something they can look at and immediately understand: what regressed, by how much, who owns it and which PRs might be responsible.

#307 improves things by splitting a very wide table into groups of 5 metrics. That’s definitely better 👍🏾 than one huge table. But with configs like node-density-cni (which has 25+ metrics...and we want to add more. @jtaleric has configs with 50+ metrics iirc) you still end up with 5 or more tables, each repeating the same time, uuid, and version columns, plus the inline ····· markers. To figure out what actually regressed, you still have to scan through all those tables looking for dotted lines and percentage changes. This is useful for perfscale engineers but it'll be time consuming for external team members

The --report output takes a different approach: it only shows the metrics that actually regressed, all in one compact table. So if 2 metrics regress out of 25+, you just see those 2 along with their values, percentage changes, and owners. No hunting through multiple tables
Also a big point is the consistency. We want the output to look the same when we run it individually (integrated) or as a massive chain (report). So this integrated mode also provides that familiarity that one can expect from orion out

I think #307 and this PR complement each other nicely and can land independently
When it comes to prow all the tables should be a part of artifacts and report as a part of stdout

As the number of metrics keeps growing, having both views available (plus --viz #290 that got merged recently should make the output a lot easier to read and act on

@vishnuchalla
Copy link
Copy Markdown
Collaborator

vishnuchalla commented Mar 10, 2026

I like the overall idea, but I don't think that the implementation should be this way. The existing collapse already condenses the output data.

For Integrated mode (--report as a flag): appends a summary report after normal orion analysis, I think we can just modify/beautify the existing --collapse --sippy-pr-search flow to have the similar form of output instead of introducing a new flag. Try this

orion --node-count true --config examples/trt-external-payload-cluster-density.yaml --lookback 30d --hunter-analyze --output-format junit --save-output-path=junit.xml --es-server '$ES_SERVER' --metadata-index '$METADATA_INDEX' --collapse --output-format json --report --sippy-pr-search

And for Standalone mode (--report file1.json,file2.json): reads pre-existing orion JSON output files and generates a consolidated regression report without running any analysis which is trying to post process the output from multiple orion runs, implementation should stay out of this repo, IMHO. May be prow is more appropriate where multiple runs chain together.

@chentex
Copy link
Copy Markdown
Member

chentex commented Mar 10, 2026

Hi @mohit-sheth I moved everything to a new PR #308 if you see the output there, you can see that it already provides a summary of what has failed making it easier to assess what was wrong with it.
Apart it just takes all the data we already have during the analysis and uses it to display the summary to the user, it is not necessary to run another analysis that outputs a json then build the summary.
Please take a look at the latest output example here

Comment thread orion/report.py Outdated
data = {}
for path in file_paths:
if not os.path.exists(path):
print(f"Warning: file not found: {path}", file=sys.stderr)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's please continue using logger as other files do in place of print.

@mohit-sheth mohit-sheth force-pushed the summary-analysis branch 3 times, most recently from 99e1489 to 1f62f63 Compare March 25, 2026 16:39
@chentex
Copy link
Copy Markdown
Member

chentex commented Mar 25, 2026

/lgtm

@mohit-sheth
Copy link
Copy Markdown
Collaborator Author

/unhold

… module

Signed-off-by: Mohit Sheth <msheth@redhat.com>
@openshift-ci openshift-ci Bot removed the lgtm label Apr 8, 2026
@chentex
Copy link
Copy Markdown
Member

chentex commented Apr 9, 2026

/lgtm

@openshift-ci openshift-ci Bot added the lgtm label Apr 9, 2026
Copy link
Copy Markdown
Member

@afcollins afcollins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

Unit tests would be good to add with new code. No failures in my tests suite.

$ orion --report output_payload-node-density-cni.json                                                                                 
                                                                   
╔════════════════════════════════════════════════════╗                                                                                                                                                                                                                       
║              Orion Regression Report               ║         
╚════════════════════════════════════════════════════╝                                                                                                                                                                                                                       
                                                                   
─── payload-node-density-cni ─── REGRESSION DETECTED              
                                                                                                                                      
Regression(s) found :                                                                                                                 
--------------------------------------------------                                                                                    
Test: payload-node-density-cni:                                                                                                       
Changepoint at:      4.22.0-0.nightly-2026-03-11-034211                                                                               
Previous version:    4.22.0-0.nightly-2026-03-10-194001                                                                               
Build:               https://...ci-main-aws-4.22-nightly-x86-payload-control-plane-6nodes/2031577334372372480                                                                      
                                                                                                                                      
Affected Metrics                                                                                                                      
+---------------------+---------+---------------------+-------------------+                                                           
| Metric              |   Value | Percentage change   | Labels            |                                                           
+=====================+=========+=====================+===================+                                                           
| podReadyLatency_P99 |   14500 | 358.82%             | [Jira: PerfScale] |                                                           
+---------------------+---------+---------------------+-------------------+                                                           
                                                                   
Other PRs in payload (40):                      

@openshift-ci
Copy link
Copy Markdown

openshift-ci Bot commented Apr 9, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afcollins

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci Bot added the approved label Apr 9, 2026
@openshift-merge-bot openshift-merge-bot Bot merged commit 3fdaaeb into cloud-bulldozer:main Apr 9, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants