Add Component Readiness dashboard for Cluster Observability Operator (COO)

[IshwarKanse]

Add Component Readiness dashboards for Cluster Observability Operator (COO)

Overview

This PR adds support for tracking Component Readiness for the Cluster Observability Operator (COO) as a separate layered product dashboard. COO consists of a number of components and we need a similar dashboard as OpenShift core to track the readiness for the components.

Component Readiness views are added for COO across actively supported OCP versions (4.16-4.21).

Changes

Configuration Views (config/views.yaml)

Added Component Readiness views for COO across OCP versions:

• 4.21-lp-Interop-coo: Compares 4.21 vs 4.20
• 4.20-lp-Interop-coo: Compares 4.20 vs 4.19
• 4.19-lp-Interop-coo: Compares 4.19 vs 4.18
• 4.18-lp-Interop-coo: Compares 4.18 vs 4.17
• 4.17-lp-Interop-coo: Compares 4.17 vs 4.16
• 4.16-lp-Interop-coo: Compares 4.16 vs 4.15

All views are configured with:

• LayeredProduct filter: lp-interop-coo
• Platforms: azure, gcp, aws
• Architectures: amd64, arm64
• Metrics and regression tracking: enabled
• Base releases use ga-30d to ga for GA'd releases

Suite Registration (pkg/db/suites.go)

• Added COO-lp-interop to the test suites list
• Fixed pre-existing typo: OpenshitPipelines-lp-interop → OpenshiftPipelines-lp-interop

Variant Registry (pkg/variantregistry/ocp.go)

• Added mapping rule: jobs containing -coo- are tagged as LayeredProduct lp-interop-coo

Snapshot (pkg/variantregistry/snapshot.yaml)

• Updated all COO job entries to use LayeredProduct: lp-interop-coo

Related Jobs

This tracks the following COO periodic jobs:

• periodic-ci-rhobs-observability-operator-main-amd64-ocp-4.12-azure-coo-stage
• periodic-ci-rhobs-observability-operator-main-amd64-ocp-4.14-azure-coo-stage
• periodic-ci-rhobs-observability-operator-main-amd64-ocp-4.15-gcp-interop-coo-production
• periodic-ci-rhobs-observability-operator-main-amd64-ocp-4.17-gcp-coo-stage-dast
• periodic-ci-rhobs-observability-operator-main-amd64-ocp-4.18-gcp-coo-stage
• periodic-ci-rhobs-observability-operator-main-amd64-ocp-4.19-gcp-coo-stage
• periodic-ci-rhobs-observability-operator-main-arm64-ocp-4.16-gcp-coo-stage
• periodic-ci-rhobs-observability-operator-main-upstream-ocp-4.19-aws-coo-compat

Testing

• Views follow the established naming pattern: {OCP_RELEASE}-lp-Interop-{product}
• Configuration aligns with other LP-Interop views (CNV, Quay, ServiceMesh, etc.)
• Metrics and regression tracking enabled for proactive monitoring

[openshift-ci-robot]

Pipeline controller notification
This repository 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. Review these jobs and use /test <job> to manually trigger optional jobs most likely to be impacted by the proposed changes.

[coderabbitai]

Walkthrough

Adds the layered-product identifier lp-interop-coo across configs and registry: six new component_readiness entries for 4.16–4.21 in config/views.yaml, a test suite addition, a layered-product pattern mapping, and many CI snapshot entries updated to set LayeredProduct: lp-interop-coo.

Changes

Cohort / File(s)	Summary
Component readiness configs config/views.yaml	Adds six new 4.21-lp-Interop-coo, 4.20-lp-Interop-coo, 4.19-lp-Interop-coo, 4.18-lp-Interop-coo, 4.17-lp-Interop-coo, 4.16-lp-Interop-coo entries under component_readiness. Each entry defines base_release/sample_release, variant_options (Architecture, Platform, include_variants with LayeredProduct: lp-interop-coo, Owner, Platform, Architecture constraints), grouping keys, identical advanced_options, and flags metrics: true, regression_tracking: true, prime_cache: false.
Test suite registration pkg/db/suites.go	Fixes typo and normalizes existing entry (OpenshiftPipelines-lp-interop) and adds new suite "COO-lp-interop" to the testSuites slice.
Layered product mapping pkg/variantregistry/ocp.go	Adds layered-product matching rule: substring -coo- now maps to lp-interop-coo in setLayeredProduct layeredProductPatterns.
Snapshot updates pkg/variantregistry/snapshot.yaml	Sets LayeredProduct from none to lp-interop-coo for numerous periodic CI job entries (multiple OCP versions/platforms) across the snapshot file.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Inspect config/views.yaml for schema conformity and consistent values across the six new release entries.
• Verify the new -coo- pattern in pkg/variantregistry/ocp.go does not conflict with existing layered-product patterns.
• Spot-check pkg/variantregistry/snapshot.yaml updates to ensure job metadata besides LayeredProduct remains correct.
• Confirm pkg/db/suites.go suite name change/addition matches downstream expectations (naming/usage).

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Go Error Handling	❓ Inconclusive	Go source files (pkg/db/suites.go, pkg/variantregistry/ocp.go) are not accessible in the sandbox environment, preventing examination of error handling patterns.	Verify repository access and provide actual code snippets showing modifications, particularly error handling in ocp.go's setLayeredProduct function and suites.go updates.

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title accurately summarizes the main change: adding Component Readiness dashboard support for Cluster Observability Operator (COO), which is the primary objective evident across all modified files.
Sql Injection Prevention	✅ Passed	Changes consist entirely of configuration and data mapping updates (YAML files, test suite entries, variant registry patterns) with no SQL query construction or database operations.
Excessive Css In React Should Use Styles	✅ Passed	The custom check for 'Excessive CSS in React Should Use Styles' is not applicable to this pull request. The PR modifies configuration and Go source files, not React/JSX/TSX files.
Single Responsibility And Clear Naming	✅ Passed	The pull request maintains clear single responsibility across all modified packages with descriptive, action-oriented naming throughout.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: IshwarKanse
Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

config/views.yaml (1)

1521-1522: Consider enabling prime_cache for better dashboard performance.

The prime_cache setting is disabled (enabled: false), while similar component readiness configurations like 4.21-main (line 81), 4.20-main (line 490), and 4.19-main (line 961) have it enabled.

Prime caching improves dashboard load times. Unless there's a specific reason to disable it for COO (e.g., this is experimental), consider setting it to true once the dashboard is stable.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 99212a4 and ac9b023.

📒 Files selected for processing (4)

• config/views.yaml (1 hunks)
• pkg/db/suites.go (1 hunks)
• pkg/variantregistry/ocp.go (1 hunks)
• pkg/variantregistry/snapshot.yaml (10 hunks)

🔇 Additional comments (4)

pkg/db/suites.go (1)

70-70: LGTM! Suite addition follows established pattern.

The addition of "COO-lp-interop" is consistent with other layered product test suites already in the list.

pkg/variantregistry/ocp.go (1)

1107-1107: LGTM! Pattern mapping is consistent with other layered products.

The "-coo-" pattern correctly identifies COO jobs and maps them to the "lp-interop-coo" variant, consistent with the job names listed in the PR description (e.g., periodic-ci-rhobs-observability-operator-main-*-coo-stage).

config/views.yaml (1)

1479-1522: Verify the minimal configuration scope for the COO dashboard.

The new coo-component-readiness configuration looks structurally correct and follows established patterns. However, there are a few scope considerations to verify:

1. Release coverage: The configuration tracks releases 4.18→4.19, but the PR description mentions 10 COO jobs spanning OCP versions 4.12 through 4.19. Is the intention to start with 4.18→4.19 and expand later, or should there be additional configurations for other release pairs?

2. Minimal variant filtering: The include_variants section is quite minimal compared to other component readiness configurations:

   • Only includes Architecture and Platform in column_group_by (lines 1489-1491)
   • Only includes Architecture, Platform, and Suite in db_group_by (lines 1492-1495)
   • Doesn't specify Network, Topology, Installer, FeatureSet variants in include_variants

   This minimal approach may be intentional for a new dashboard, but please confirm this matches your requirements.

3. Suite handling: Suite is included in db_group_by (line 1495) but not explicitly filtered in include_variants. This means all suite values will be included, which may be correct for COO jobs.

pkg/variantregistry/snapshot.yaml (1)

238329-238545: Snapshot regeneration is correct and properly reflects the COO layered product mapping.

The "-coo-" pattern mapping is confirmed in pkg/variantregistry/ocp.go (line 1107): {"-coo-", "lp-interop-coo"}. All 10 job entries in the diff contain this pattern and are correctly assigned LayeredProduct: lp-interop-coo. The snapshot generation logic in snapshot.go and the test in ocp_test.go confirm this is auto-generated and properly validated. The changes are valid.

[openshift-ci-robot]

Scheduling required tests:
/test e2e

[IshwarKanse]

@neisw @xueqzhan Can you help to review this PR, thanks.

[neisw]

@IshwarKanse I think you need to update ci-test-mapping suites first similar to ci-test-mapping#501

[IshwarKanse]

• ci/prow/security

@neisw Added the COO mapping to testSuites. openshift-eng/ci-test-mapping#531

[IshwarKanse]

/test ci/prow/security

[openshift-ci]

@IshwarKanse: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

/test build

/test e2e

/test images

/test lint

/test security

/test unit

/test yaml-lint

Use /test all to run the following jobs that were automatically triggered:

pull-ci-openshift-sippy-main-build

pull-ci-openshift-sippy-main-images

pull-ci-openshift-sippy-main-lint

pull-ci-openshift-sippy-main-security

pull-ci-openshift-sippy-main-unit

pull-ci-openshift-sippy-main-yaml-lint

In response to this:

/test ci/prow/security

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.

[IshwarKanse]

/test security

[openshift-ci-robot]

Scheduling required tests:
/test e2e

[openshift-ci-robot]

Scheduling required tests:
/test e2e

[IshwarKanse]

/test e2e

[openshift-ci]

@IshwarKanse: all tests passed!

Full PR test history. Your PR dashboard.

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.

[IshwarKanse]

@neisw Fixed the existing typo issue reported by coderabbit and updated the 4.19 view.