INTEROP-9317: Add OPP LP interop variant and CR view for OCP 4.22

[amp-rh]

Add layered product pattern for OPP multi-LP interop jobs (ACM + ODF + Quay), CR dashboard view 4.22-LP-Interop--OPP, and unit tests for job name classification.

Tracked by: INTEROP-9317 | Epic: INTEROP-9202

Summary by CodeRabbit

• New Features

  • Added support for identifying OPP layer-interoperability jobs in release analysis.
  • Added release 4.22 configuration with sampling, variant grouping, filtering, ownership selection, thresholds, and metrics settings.
  • Classified applicable jobs as lp-interop--OPP and updated their release status to candidate.

• Tests

  • Added coverage for OPP interoperability jobs on AWS and vSphere.

[openshift-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: automatic mode

[openshift-ci-robot]

@amp-rh: This pull request references INTEROP-9317 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Add layered product pattern for OPP multi-LP interop jobs (ACM + ODF + Quay), CR dashboard view 4.22-LP-Interop--OPP, and unit tests for job name classification.

Tracked by: INTEROP-9317 | Epic: INTEROP-9202

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[coderabbitai]

Walkthrough

The change classifies -interop-opp- jobs as lp-interop--OPP, updates related snapshots, adds AWS and vSphere tests, and configures the 4.22-LP-Interop--OPP analysis view.

Changes

OPP interoperability support

Layer / File(s)	Summary
Classify and validate OPP interoperability jobs pkg/variantregistry/ocp.go, pkg/variantregistry/ocp_test.go, pkg/variantregistry/snapshot.yaml	Job names containing -interop-opp- receive the lp-interop--OPP layered product. AWS and vSphere tests cover the classification. Six snapshots now use candidate tier and the new layered product.
Configure the 4.22 OPP view config/views.yaml	The 4.22-LP-Interop--OPP view targets lp-interop--OPP, mpiit, and OVN with 4.21-to-4.22 release windows and regression tracking.

Estimated code review effort: 2 (Simple) | ~15 minutes

Suggested reviewers: dgoodwin, neisw, oharan2

---

Caution

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

• Ignore

❌ Failed checks (1 error, 1 warning)

Check name	Status	Explanation	Resolution
Stable And Deterministic Test Names	❌ Error	The added cases run as t.Run(test.job, ...), so their titles are full CI job names with release and platform details that can change in later iterations.	Use stable descriptive names such as OPP interop AWS and OPP interop vSphere; keep the full job strings only in the test data and assertions.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (19 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Go Error Handling	✅ Passed	The Go diff adds only a map-pattern literal and classification test data; it introduces no ignored errors, panic calls, unchecked error returns, or pointer dereferences.
Sql Injection Prevention	✅ Passed	The commit adds no SQL construction. Its static LayeredProduct filter uses existing BigQuery @parameter binding; the dataset formatting in ocp.go predates this commit.
Excessive Css In React Should Use Styles	✅ Passed	The PR changes only YAML and Go files. The diff adds no React components, JSX, inline style objects, or CSS requiring useStyles.
Test Coverage For New Features	✅ Passed	The new -interop-opp- classification is covered by two TestVariantSyncer cases for AWS and vSphere, which assert lp-interop--OPP; configuration and snapshot changes are exempt.
Single Responsibility And Clear Naming	✅ Passed	The change adds one clear layered-product pattern and one focused OPP dashboard view; existing setLayeredProduct remains cohesive, and names match repository conventions.
Feature Documentation	✅ Passed	The PR adds a layered-product classifier and a Component Readiness view, but no existing docs/features file covers these concepts; documentation updates are encouraged, not required.
Test Structure And Quality	✅ Passed	The added cases are pure table-driven Go unit tests, not Ginkgo or cluster tests; they create no resources, use no waits, and follow the package's existing t.Run/assert.Equal pattern.
Microshift Test Compatibility	✅ Passed	The PR adds standard Go table-driven tests in pkg/variantregistry/ocp_test.go, not Ginkgo e2e tests; no MicroShift compatibility check is required.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	The added tests are standard Go table-driven tests (TestVariantSyncer with t.Run), not Ginkgo e2e tests, and they make no SNO multi-node assumptions.
Topology-Aware Scheduling Compatibility	✅ Passed	The commit changes only a dashboard YAML view, variant classification, tests, and snapshots; it adds no manifests, operators, controllers, or scheduling constraints.
Ote Binary Stdout Contract	✅ Passed	The PR adds config, variant matching, tests, and snapshot data; added Go code has no stdout writes or process-level hooks, and no OTE/Ginkgo suite entry points are present.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	The added cases are standard Go table tests under TestVariantSyncer, not Ginkgo e2e tests. They perform no networking or external connectivity.
No-Weak-Crypto	✅ Passed	The patch adds YAML, a layered-product substring, and variant tests only; added lines contain no MD5, SHA1, DES, RC4, Blowfish, ECB, crypto API, or secret-comparison code.
Container-Privileges	✅ Passed	The PR changes only dashboard configuration, Go code/tests, and variant snapshot data; no changed file is a container/Kubernetes manifest and no privilege markers appear in added lines.
No-Sensitive-Data-In-Logs	✅ Passed	The patch adds no logging calls and no passwords, tokens, keys, PII, hostnames, or customer data; it only adds configuration, classification, tests, and snapshot values.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main changes: adding the OPP layered-product interop variant and the OCP 4.22 CR view.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[amiskin94]

/test all

[redhat-chai-bot]

Review — INTEROP-9317: Add OPP LP interop variant and CR view for OCP 4.22

Overall this is a clean, well-structured PR that follows existing conventions in the codebase. The four changes (pattern matcher, tests, snapshot, view config) are internally consistent. A few observations and suggestions below.

✅ Looks Good

• Pattern placement in ocp.go: The new {"-interop-opp-", "lp-interop--OPP"} entry is placed correctly — after the more specific ACM entries and before the broad -virt / -cnv / -kubevirt matchers. Since setLayeredProduct is first-match-wins and the job name is lowercased before matching, this ordering avoids false positives.
• View config: The 4.22-LP-Interop--OPP view in views.yaml follows the same structure as sibling LP interop views (base release 4.21 GA window, sample release 4.22 now-30d, OVN network, mpiit owner). The include_variants correctly references lp-interop--OPP.
• Snapshot updates: The six jobs (4.22 + 5.0, AWS + vSphere + upgrade) are correctly reclassified from LayeredProduct: none / JobTier: informing to LayeredProduct: lp-interop--OPP / JobTier: candidate.
• Tests: Two test cases cover AWS and vSphere platforms and assert the full variant map including VariantLayeredProduct: "lp-interop--OPP".

💡 Suggestions / Questions

1. Test coverage for the upgrade job name pattern: The snapshot includes an upgrade job (periodic-ci-stolostron-policy-collection-main-ocp4.22-upgrade-interop-opp-upgrade-aws) which also gets reclassified, but there's no corresponding test case for this pattern. Adding one would verify that the upgrade variant fields (e.g. VariantUpgrade, FromRelease*) are set correctly alongside the new layered product classification.

2. Test job names vs. snapshot job names: The test cases use job names with an lp- prefix (e.g. ocp4.22-lp-interop-opp-aws), while the snapshot has jobs without it (e.g. ocp4.22-interop-opp-aws). Both contain the matching substring -interop-opp- so the pattern works for both, but consider adding a test case that mirrors the exact snapshot job name for completeness — it would confirm the real-world jobs are classified as expected.

3. 5.0 view: The snapshot correctly reclassifies 5.0 OPP jobs as well, but there's no 5.0-LP-Interop--OPP view in this PR. Is that intentional (perhaps a follow-up), or should it be included here?

Summary

The code changes are correct and follow established patterns. The suggestions above are minor improvements to test coverage and completeness — none are blockers. Nice work! 👍

---

AI-generated. Review for accuracy.

[amp-rh]

Chai Bot Review

Automated review via Chai Bot

Summary

This PR correctly adds OPP (ACM + ODF + Quay) multi-LP interop job classification and a Component Readiness dashboard view for OCP 4.22.

What Works Well

• Pattern placement is correct. "-interop-opp-" is inserted before -virt/-cnv/-kubevirt in the first-match-wins list, preventing OPP jobs from being misclassified.
• Trailing-dash guard. The trailing dash in "-interop-opp-" prevents false matches on hypothetical jobs like -interop-oppsec-.
• Naming consistency. lp-interop--OPP follows established LP interop conventions.
• JobTier change is correct. informing → candidate is a correct side effect of adjustJobTierBasedOnView, not a manual override.
• View structure mirrors 4.22-LP-Interop--lpMainline appropriately.

Concerns

⚠️ Medium: BigQuery SQL coverage for old-style job names

The BQ query uses LIKE 'periodic-ci-%%-lp-interop-%%' which catches new-style names (with lp- prefix). The snapshot also contains older-style names like periodic-ci-stolostron-...-interop-opp-aws (no lp- prefix) that wouldn't match. This is a pre-existing issue, not introduced by this PR, but worth confirming whether old-style jobs are still active.

ℹ️ Low: Missing 5.0 view?

The snapshot includes OPP jobs for both 4.22 and 5.0, but only a 4.22 view is added. If 5.0 OPP jobs should be visible in CR, a 5.0-LP-Interop--OPP view would be needed. This might be intentional if 5.0 isn't ready yet.

ℹ️ Low: Test coverage for old-style job names

Unit tests cover only the new lp-interop-opp naming. A test case with the old-style name (interop-opp, no lp- prefix) would verify both conventions work.

Suggestions

1. Verify whether old-style interop-opp (no lp- prefix) job names still exist in CI. If so, consider adding a BQ SQL pattern.
2. Consider adding a test case with the old naming convention for documentation and coverage.
3. Consider a 5.0-LP-Interop--OPP view in this PR or a follow-up.

Overall Assessment

✅ This PR looks good and is safe to merge. Pattern logic is correct, ordering is safe, test coverage is solid for the primary use case, view structure follows conventions, and snapshot changes are correct side effects of proper LP classification.

[amp-rh]

/pj-rehearse ack

[amiskin94]

/pj-rehearse ack

[xueqzhan]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amp-rh, xueqzhan

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:

• OWNERS [xueqzhan]

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

[amp-rh]

/pj-rehearse ack

[amp-rh]

/test e2e

[amp-rh]

/retest

[amp-rh]

/test e2e

[amp-rh]

/test e2e

[openshift-merge-bot]

/retest-required

Remaining retests: 0 against base HEAD 5da7ac2 and 2 for PR HEAD a961047 in total

[redhat-chai-bot]

/retest

---

AI-generated. Review for accuracy.

[amp-rh]

/retest

[openshift-merge-bot]

/retest-required

Remaining retests: 0 against base HEAD ff252ad and 1 for PR HEAD a961047 in total

[amp-rh]

/retest

[amp-rh]

/retest

[amp-rh]

/retest

[amp-rh]

/retest

[amiskin94]

/retest

[amp-rh]

/retest

[amp-rh]

/retest

[amp-rh]

/retest

[amp-rh]

/retest

[neisw]

/test e2e

[amiskin94]

/retest

[xueqzhan]

/retest-required

[openshift-ci]

@amp-rh: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.