-
Notifications
You must be signed in to change notification settings - Fork 46
Add tracing-uiplugin component #541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Hi @IshwarKanse. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
Requested to be added to the Github org. |
|
/verify-owners |
|
/ok-to-test |
88e68fd to
a8c8d04
Compare
Assisted by Claude Code
|
/lgtm |
|
@IshwarKanse: you cannot LGTM your own PR. DetailsIn response to this:
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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: IshwarKanse The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@neisw Can you help to review and approve this PR. I have updated our tests to add the matching testsuite name and capability tags but the jobs haven't run after the change so we don't have the data in BigQuery yet, with the updated test changes. But I have simulated locally and the mapping is working well. The jobs will now be run after the year end recharge. Once this component data shows correctly on the dashboard, I will reach out to our Cluster Observability Operator component teams to add their components similarly. |
| Component: &config.Component{ | ||
| Name: "tracing-uiplugin", | ||
| Operators: []string{"cluster-observability-operator"}, | ||
| DefaultJiraProject: "COO", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably need to review what you need here. I don't think there is full support for Jira projects other than OCPBUGS currently for CR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback @neisw! I did some investigation using Claude Code of both the ci-test-mapping and Sippy codebases to understand the limitations.
What I Found
I found only one limitation for non-OCPBUGS Jira projects:
Triage Auto-Commenting (sippy/pkg/api/componentreadiness/triage.go:140-141)
if !strings.HasPrefix(jiraCard, "OCPBUGS") {
logger.Warnf("URL (%s) is not an OCPBUGS card, cannot comment", triage.URL)
return
}- When users triage test failures and link them to Jira issues, Sippy won't automatically add comments to COO Jira cards
- This is a convenience feature.
What Works
I verified that all core Component Readiness features properly support non-OCPBUGS projects:
✅ Test Data Storage - sippy/pkg/apis/sippy/v1/types.go:95-96
// JiraProject specifies the JIRA project that this variant belongs to.
JiraProject string `bigquery:"jira_project"`✅ Variant Mappings - sippy/pkg/componentreadiness/jiraautomator/jiraautomator.go:636
result[Variant{...}] = JiraComponent{Project: r.JiraProject, Component: r.JiraComponent}✅ Jira Automation - Not applicable to COO
- COO dashboards have
regression_tracking: enabled: falseinconfig/views.yaml - While
jiraautomator.go:546defaults to OCPBUGS for row-based components, this code path isn't used for COO since automation is disabled
✅ Dashboard Configuration - sippy/config/views.yaml
- COO dashboards filter by
LayeredProduct: lp-interop-coo, not by Jira project - No Jira project restrictions in dashboard definitions
✅ Queries and Filtering - sippy/pkg/api/componentreadiness/query/querygenerators.go
- No hardcoded OCPBUGS requirements in query generation
- Only reference to OCPBUGS is a comment about a bug (line 40)
✅ Frontend Bug Filing - sippy-ng/src/bugs/FileBug.js
- Takes
jiraComponentIDandjiraComponentNameas generic props - No hardcoded project restrictions
The system is properly architected to support multiple Jira projects - the data model, queries, and dashboards all handle it correctly.
My Plan
We can keep the COO project since:
- It aligns with our team's Jira workflow
- All core functionality works (statistics, dashboards, data storage)
- We only lose one convenience feature (triage auto-commenting)
- Jira automation doesn't apply to COO (regression tracking is disabled)
- The enhancement to support other projects should be straightforward (removing one hardcoded check). I can work on it in another PR.
Does this work, or are there other concerns we should address?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @IshwarKanse, I double checked with the team and our code and unfortunately there is still a dependency that components be defined in OCPBUGS project. We do understand that this is a limitation for teams who do not typically work within the OCPBUGS project and are trying to utilize CR. For the near term you will need to define a component within OCPBUGS and associate your suite with it for CR to display the results properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @neisw for the clarification! I've reviewed the code and understand the limitation.
You're right - both ci-test-mapping (pkg/jira/ocpbugs.go:19) and Sippy (pkg/dataloader/jiraloader/jiraloader.go:122) hardcode the OCPBUGS project ID when loading component IDs.
I also found that bug filing is hardcoded to OCPBUGS (pkg/sippyserver/server.go:1675), so filing bugs from Sippy UI won't work for COO components.
What Works vs What Doesn't
| Feature | With COO Project |
|---|---|
| Dashboard display | ✓ Works |
| Statistics & regressions | ✓ Works |
| Bug filing from Sippy UI | ✗ Won't work (must file directly in COO Jira) |
| Triage auto-commenting | ✗ Won't work |
The core dashboard functionality works because jira_component_id isn't used for filtering (there's even a TODO at querygenerators.go:311 noting it appears unused).
Our Situation
We can't create a component in OCPBUGS since COO is a layered product with its own Jira project and it has many components. I noticed other layered products (CNV, ODF, Quay) work around this by creating components in OCPBUGS, but we'd prefer to keep proper Jira alignment as all the bugs being reported against COO components will mix with the bugs in OCPBUGS jira project.
We're OK accepting these limitations (no Sippy bug filing, no triage commenting) in exchange for proper COO Jira project alignment. Our teams will file bugs directly in COO Jira.
That said, if you'd prefer we follow the existing pattern for consistency, we can remove DefaultJiraProject: "COO" and create the components in OCPBUGS instead. Let me know your preference and I'll update the PR accordingly. Thank you for your time looking into this.
Add tracing-uiplugin Component for Distributed Tracing UI plugin
Summary
This PR adds a new component
tracing-uipluginto map distributed tracing UI plugin E2E tests to the Component Readiness dashboard. Integrates with the COO layered product dashboard (Sippy PR #3109).Changes Made
1. New Component: tracing-uiplugin
Location:
pkg/components/clusterobservabilityoperator/tracinguiplugin/Component Configuration:
2. Component Registration
File:
pkg/registry/registry.gotracinguiplugin "github.com/openshift-eng/ci-test-mapping/pkg/components/clusterobservabilityoperator/tracinguiplugin"r.Register("tracing-uiplugin", &tracinguiplugin.ClusterObservabilityOperatorComponent)Note: Component organized in subdirectory structure to allow other COO teams (e.g., logging-uiplugin) to easily add their components in parallel directories.
3. Suite Configuration
File:
config/openshift-eng.yamltracing-uiplugintoincludeSuitesTest Suite Integration
Test Repository
Repository: openshift/distributed-tracing-console-plugin
Test File: tests/e2e/dt-plugin-tests.cy.ts
Test Suite Name
Test Capabilities
All 6 tests include
[Capability:XXX]tags that are automatically extracted:Test 1: Empty State
Capabilities: UIPlugin, EmptyState
Test 2: Trace Visualization & RBAC
Capabilities: UIPlugin, TraceVisualization, SpanLinks, RBAC
Test 3: Trace Limits
Capabilities: UIPlugin, TraceLimits
Test 4: Cutoff Box & Time Range
Capabilities: UIPlugin, TraceVisualization, TimeRange
Test 5: AI Integration
Capabilities: UIPlugin, AIIntegration, Lightspeed
Test 6: Operator Lifecycle
Capabilities: OperatorLifecycle, Installation
Capability Summary
Total Tests: 6
Total Capabilities: 11
Testing & Verification
Build Verification
Mapping Verification
No Tests Moved to Unknown
$ ./ci-test-mapping map-verify # ✅ verification complete in 3.188866625sFiles Changed
Team Ownership
OWNERS file added with the following reviewer/approver:
References