diff --git a/.claude/skills.json b/.claude/skills.json new file mode 100644 index 0000000000..a917438055 --- /dev/null +++ b/.claude/skills.json @@ -0,0 +1,9 @@ +{ + "skills": [ + { + "name": "pdhelper", + "description": "Track progressive delivery status of commits across environments", + "file": "skills/pdhelper.md" + } + ] +} \ No newline at end of file diff --git a/.claude/skills/pdhelper.md b/.claude/skills/pdhelper.md new file mode 100644 index 0000000000..e39748b77d --- /dev/null +++ b/.claude/skills/pdhelper.md @@ -0,0 +1,707 @@ +# Progressive Delivery Helper (pdhelper) + +## Purpose + +Help users understand and track the progressive delivery status of commits in OpenShift organization repositories on GitHub. + +## Session Initialization + +**At the start of each session**, perform the following steps: + +### Step 1: Update Local App-Interface Repository + +Before requesting permissions, check for and update the local app-interface repository: + +1. Check if `../app-interface` directory exists relative to the current working directory +2. If it exists: + - Navigate to the directory + - Run `git fetch origin` to fetch latest changes + - Run `git checkout master` to ensure on master branch + - Run `git pull origin master` to update to latest + - Inform user if update was successful or if there were any issues +3. If it doesn't exist: + - Inform user that app-interface repository was not found + - Ask user if they want to provide the path to their local app-interface clone + +**Example update sequence:** +```bash +cd ../app-interface +git fetch origin +git checkout master +git pull origin master +cd - +``` + +### Step 2: Request Blanket Read-Only Permissions + +After updating app-interface, request blanket **READ-ONLY** permissions for the entire session: + +**IMPORTANT**: All permissions are READ-ONLY. No write, edit, or modification permissions will be requested or granted. + +1. **Quay.io API Access (READ-ONLY)**: Request permission to curl `https://quay.io/api/v1/repository/redhat-services-prod/*` for checking Konflux build status and latest image tags +2. **App-interface Repository Access (READ-ONLY)**: Request permission to search and read files in `../app-interface/**` for: + - Finding saas files for any component + - Reading deployment configurations + - Checking app.yml files for hotfix versions + - Reading pipeline provider configurations +3. **GitHub Web Access (READ-ONLY)**: Request permission to fetch public GitHub pages at `https://github.com/openshift/*` for: + - Viewing commit details and timestamps + - Reading commit messages and metadata + - Checking branch status and commit history + - Comparing commits to calculate deployment gaps +4. **GitHub API Access (READ-ONLY)**: Request permission to access GitHub API at `https://api.github.com/repos/openshift/*` for: + - Retrieving commit information programmatically + - Checking repository status + - Fetching branch and tag data +5. **Git Operations (READ-ONLY)**: Request permission to: + - Check for existing repository clones in `../` (parent directory) first + - Clone GitHub repositories to `/tmp` only if not found locally for commit analysis and comparison (read-only clones) + +**Example request at session start:** +``` +To help you track commit deployments, I need READ-ONLY permission for this session to: +1. Update local app-interface repository (../app-interface) to latest master branch via git pull +2. Curl Quay.io API (quay.io/api/v1/repository/redhat-services-prod/*) to check built images +3. Search and read files in ../app-interface/** to find and analyze deployment configurations +4. Fetch public GitHub pages at https://github.com/openshift/* to view commit details +5. Read from GitHub API at https://api.github.com/repos/openshift/* for repository data +6. Clone repositories to /tmp for commit analysis (read-only) + +All permissions are READ-ONLY. No write or modification operations will be performed. + +May I proceed with these permissions for the duration of our session? +``` + +**Note**: +- Only public GitHub repositories and APIs in the `openshift` organization are accessed +- No private repository access or authentication is requested +- The app-interface repository is accessed locally from your filesystem +- **All operations are READ-ONLY - no files will be written, edited, or modified except for updating the app-interface repository itself via git pull** + +Once granted, these permissions apply to all subsequent queries in the session without re-asking. + +## Command Keywords + +Users can invoke pdhelper using standardized command patterns: + +### Status Commands +- `pdhelper status ` - Get overall deployment status for a component +- `pdhelper where is for ` - Check where a specific commit is deployed +- `pdhelper what is the status of deployments on ` - Alias for status command + +### Query Commands +- `pdhelper latest ` - Show latest Quay build and compare with deployed versions +- `pdhelper diff ` - Show deployment gap analysis across environments +- `pdhelper short ` - Show ONLY the deployment gap analysis section (concise) + +### Team Commands +- `pdhelper team ` - Show deployment status for all components owned by a team + - Available teams: `rocket`, `aurora`, `thor`, `hulk`, `orange`, `security` + - Returns concise deployment gap analysis for each component owned by the team + +### Help Commands +- `pdhelper help` - Show all available commands in a concise list +- `pdhelper how` - Alias for help command + +### Examples: +``` +pdhelper status route-monitor-operator +pdhelper where is f3edcbc for osd-metrics-exporter +pdhelper what is the status of deployments on route-monitor-operator +pdhelper latest must-gather-operator +pdhelper short route-monitor-operator +pdhelper team thor +pdhelper team hulk +``` + +**Command Recognition**: When user input matches these patterns, execute the corresponding workflow automatically. + +**IMPORTANT - After Every Response**: Always end your response with a suggestion for other useful pdhelper commands the user might want to try. Format it as: +``` +πŸ’‘ You might also want to try: +- `pdhelper status ` - Full deployment status +- `pdhelper where is for ` - Track a specific commit +- `pdhelper latest ` - Latest Quay build comparison +``` +Choose 2-3 relevant commands based on what the user just asked. If they used `short`, suggest `status` for more details. If they used `status`, suggest `where is` for specific commits. + +### Command Output Formats + +**`pdhelper short `** returns ONLY: +``` +πŸ“Š Deployment Status: +- Latest commit on repository: () +- Latest Konflux build: () +- Integration: βœ…/⚠️ +- Stage: βœ…/⚠️ +- Production: βœ…/⚠️ () +``` + +**`pdhelper team `** returns: +``` +🎯 Team Deployment Status + +## +πŸ“Š Deployment Status: +- Latest commit on repository: () +- Latest Konflux build: () +- Integration: βœ…/⚠️ +- Stage: βœ…/⚠️ +- Production: βœ…/⚠️ () + +## +πŸ“Š Deployment Status: +- Latest commit on repository: () +- Latest Konflux build: () +- Integration: βœ…/⚠️ +- Stage: βœ…/⚠️ +- Production: βœ…/⚠️ () + +[... for each component owned by the team] +``` + +**`pdhelper help`** or **`pdhelper how`** returns: +``` +πŸ“š PDHelper Commands + +Status Commands: + pdhelper status - Full deployment status + pdhelper short - Concise deployment status + pdhelper where is for - Track specific commit + +Query Commands: + pdhelper latest - Latest Quay build comparison + pdhelper diff - Deployment gap analysis + +Team Commands: + pdhelper team - Team deployment status + Available teams: rocket, aurora, thor, hulk, orange, security + +Examples: + pdhelper short route-monitor-operator + pdhelper team rocket + pdhelper where is f3edcbc for osd-metrics-exporter +``` + +## Core Capabilities + +### Commit Status Tracking +- Check the progressive delivery status of a specific commit SHA +- Identify which environments a commit has been deployed to +- Track promotion progress across integration β†’ stage β†’ production +- Understand which gates/channels a commit has passed + +## Key Knowledge Areas + +### Progressive Delivery Pipeline Structure + +For OpenShift repositories (e.g., github.com/openshift/osd-example-operator): + +1. **Commit Flow**: + - Developer commits code β†’ GitHub repository + - Konflux pipeline builds and tests β†’ Creates image with commit SHA + - Component promotion through environments based on saas file configuration + +2. **Environment Progression**: + - **Integration (int)**: First deployment target, watches quay `image` to trigger + - **Int e2e gate**: Int e2e gate target, watches int deploy success to trigger + - **Stage**: Deployed after integration success, watches int e2e gate to trigger + - **Stage e2e gate**: Stage e2e gate target, watches stage deploy success to trigger + - **Production Canary**: Manual gate before full production, stage gate must be successful for this + - **Production Phases**: Multiple production hives with phased rollout, with 12h soak between phases + - **Hotfix**: hotfixVersion in app.yaml allows any commit to be deployed to a target regardless of subscribed channel state + +3. **Status Channels**: + - Channels follow pattern: `{component}-{resource-type}-{status}-channel-{environment}` + - Example: `must-gather-operator-sss-deployed-success-channel-int01` + - Success channels indicate successful deployment to that environment which triggers a job subscribing to this channel + +## Workflow Patterns + +### Check Commit Deployment Status + +**Step 1**: Identify the repository and commit SHA +``` +Repository: github.com/openshift/must-gather-operator +Commit SHA: 487f70e4b17b63bb1f821bf7ebe0647eeb14e225 (or query for latest) +``` + +**Step 2**: Locate the saas file first to determine trigger type +``` +Path: ../app-interface/data/services/osd-operators/cicd/saas/saas-must-gather-operator.yaml +``` + +**IMPORTANT - PKO Saas File Priority Rule:** +- If a component has BOTH a regular saas file AND a `-pko.yaml` saas file, **ONLY use the `-pko.yaml` file** +- Example: If both `saas-osd-metrics-exporter.yaml` and `saas-osd-metrics-exporter-pko.yaml` exist, use ONLY `-pko.yaml` +- The `-pko.yaml` file represents the Package Operator deployment which is the current/active deployment method +- The regular saas file is typically deprecated/legacy OLM-based deployment +- When searching for saas files, prioritize `-pko.yaml` variants and ignore non-PKO versions if PKO exists + +**Step 3**: Determine if component uses Quay image triggers or upstream CI triggers +Check the integration target configuration: +- **Uses Quay image trigger**: Integration target has `ref: main` or `ref: master` with an `images:` section that watches Quay + - Example: `osd-metrics-exporter-pko` with `ref: main` and `images:` section + - **Action**: Query Quay API for latest Konflux build +- **Uses upstream CI trigger**: Integration target has `ref: internal` or `ref: main` with an `upstream:` section + - Example: `must-gather-operator` with `ref: internal` and `upstream: openshift-must-gather-operator-gh-build-internal` + - **Action**: Skip Quay query, use GitHub commit information only (latest commit from GitHub = latest build) + +**Step 4**: Parse the saas file and check target images +- Look through all `resourceTemplates[].targets[]` +- Check `image` field to see if it contains your commit SHA (Konflux builds images tagged with commit) +- Check `ref` field to see which commit is configured for deployment +- Compare deployed commits with latest Quay tag +- Alternatively, check if the target is watching a channel that has been triggered by your commit + +**Step 5**: Identify deployment status +- **Integration**: Target watches quay image - deployed when Konflux builds your commit +- **Int e2e gate**: Watches int deploy success channel - triggered after int deploys +- **Stage**: Watches int e2e gate channel - triggered after int e2e passes +- **Stage e2e gate**: Watches stage deploy success channel - triggered after stage deploys +- **Production Canary**: Requires stage e2e gate success - manual promotion needed +- **Production Phases**: Auto-promote after 12h soak time once canary succeeds + +**Step 6**: Report latest build information +- **ALWAYS** include in response: Latest image tag from Quay (short SHA format) and its build timestamp +- Use short commit SHA (first 7-8 characters) for readability, not full 40-character SHA +- Compare latest tag with deployed refs to show if updates are available +- Help user understand deployment lag + +**Format for Latest Build Section:** +``` +### πŸ”„ **Latest Konflux Build in Quay:** +- **Latest**: `abc1234` (short SHA) +- **Built**: Day, DD Mon YYYY HH:MM:SS UTC +- **Image**: quay.io/redhat-services-prod/openshift/{component}:abc1234 +``` + +**Step 7**: Determine next steps +- If stuck at int: Check Konflux build status and int deployment +- If stuck at int e2e gate: Wait for/check int e2e test results +- If stuck at stage: Verify int e2e gate channel succeeded +- If stuck at stage e2e gate: Wait for/check stage e2e test results +- If at canary: Manual approval needed for production rollout +- If in production phase 1: Will auto-promote to phase 2 after 12h soak + +## Best Practices + +### Understanding the Gate System +- E2E gates are separate targets that watch deployment success +- Gates run tests and publish success/failure to channels +- Downstream environments subscribe to gate channels, not deploy channels +- This ensures tests pass before promoting to next environment + +### Working with Konflux +- Konflux automatically builds images on commit to main branch +- Images are tagged with commit SHA +- Integration targets watch for new images in quay +- No manual image promotion needed for integration + +### Using Hotfixes +- Add commit SHA to `hotfixVersions` in app.yaml to bypass gates +- Useful for critical fixes that need immediate production deployment +- Use sparingly - bypasses safety gates + +### Reading Soak Times +- Production phases use 12h soak time between rollouts +- Soak time allows observation of canary before wider rollout +- Auto-promotion happens after soak time if no issues detected + +## Example Interactions + +### Example 1: Check where commit is deployed + +**User**: "Where is commit 487f70e deployed for must-gather-operator?" + +**pdhelper Response**: +1. Parse `saas-must-gather-operator.yaml` +2. Check which targets have images containing the commit SHA +3. Check which gate channels have succeeded for this commit +4. Report findings: + ``` + Commit 487f70e4b17b63bb1f821bf7ebe0647eeb14e225 status: + + βœ… Integration (int): Deployed + - Image deployed to integration hive + - Deploy success channel published + + βœ… Int e2e gate: Passed + - E2E tests completed successfully + - Gate channel published: must-gather-operator-sss-e2e-success-channel-int01 + + βœ… Stage: Deployed + - Deployed to all stage hives + - Deploy success channels published + + βœ… Stage e2e gate: Passed + - Stage E2E tests completed successfully + - Gate channel published: must-gather-operator-sss-e2e-success-channel-stage01 + + ⏸️ Production Canary: Ready for manual promotion + - Canary targets: hivep03uw1, hivep04ew2 + - Waiting for manual approval + + ⏳ Production Phases: Waiting for canary + - Phase 1 will auto-deploy 12h after canary success + - Phase 2 will auto-deploy 12h after phase 1 + + Next Step: Approve manual promotion to production canary + ``` + +### Example 2: Understand why promotion is blocked + +**User**: "Why hasn't my commit promoted to stage yet?" + +**pdhelper Response**: +1. Identify the commit SHA from the repository +2. Check saas file for gate channel subscriptions +3. Analyze blocking issue: + ``` + Commit abc123 status: + + βœ… Integration: Deployed successfully + + ❌ Int e2e gate: FAILED + - E2E tests failed in integration environment + - Channel must-gather-operator-sss-e2e-success-channel-int01 NOT published + - Error: Test suite failure in pod readiness check + + ⏸️ Stage: Blocked + - Waiting for int e2e gate success + - Cannot proceed until e2e tests pass + + Action needed: + 1. Check e2e test logs in integration environment + 2. Fix failing tests or redeploy if transient failure + 3. Once int e2e gate passes, stage will auto-deploy + ``` + +### Example 3: Track production rollout timeline + +**User**: "When will my commit reach all production hives?" + +**pdhelper Response**: +1. Map out the complete promotion chain from the saas file +2. Calculate soak times (12h between phases) +3. Provide timeline: + ``` + Production Rollout Timeline for commit def456: + + Stage e2e gate passed: Day 0, 10:00 AM + + Manual Actions Required: + - Day 0, 10:00 AM: Approve canary promotion (manual gate) + + Automatic Promotions: + - Day 0, 10:30 PM: Phase 1 auto-deploys (12h after canary) + β†’ Targets: hivep06uw2, hivep07uw2 + + - Day 1, 10:30 AM: Phase 2 auto-deploys (12h after phase 1) + β†’ Targets: hivep05ue1, hivep08ue2, hivep01ue1, hivep02ue1 + + Total time: ~24 hours from canary approval to full production + Soak time between phases: 12 hours + ``` + +### Example 4: Using hotfix for urgent deployment + +**User**: "I need to deploy a critical fix directly to production, bypassing gates" + +**pdhelper Response**: +1. Explain hotfix process +2. Provide instructions: + ``` + Hotfix Deployment Process: + + Step 1: Add commit to app.yaml hotfixVersions + + File: ../app-interface/data/services/osd-operators/must-gather-operator/app.yml + + Add under codeComponents: + ```yaml + hotfixVersions: + - abc123def456 # Your critical fix commit SHA + ``` + + Step 2: Create MR in app-interface + - This bypasses all gate requirements + - Commit will deploy to targets regardless of channel state + + Step 3: Monitor deployment + - Watch for deployment to complete + - Hotfix overrides normal promotion flow + + ⚠️ Warning: + - Use only for critical production issues + - Hotfixes bypass safety gates and testing + - Remove from hotfixVersions after normal promotion catches up + ``` + +### Example 5: Debugging stuck deployment + +**User**: "My commit has been in integration for 2 hours but hasn't moved to stage" + +**pdhelper Response**: +1. Check the gate flow +2. Identify bottleneck: + ``` + Deployment Analysis for commit xyz789: + + Timeline: + - 12:00 PM: Konflux built image with commit SHA + - 12:05 PM: Integration deployed image βœ… + - 12:06 PM: Int deploy success channel published βœ… + - 12:06 PM: Int e2e gate target triggered ⏳ + - 02:00 PM: Current time - Still waiting + + Issue: Int e2e gate is running but hasn't completed + + Diagnostic steps: + 1. Check int e2e gate job status: + β†’ Look for running e2e test pods in integration namespace + + 2. Check for stuck jobs: + β†’ E2E jobs typically take 15-30 minutes + β†’ 2 hour runtime suggests stuck job + + 3. Review e2e logs: + β†’ Check for timeout or resource issues + + Recommended action: + - Investigate e2e gate job logs + - Consider restarting stuck e2e job if infrastructure issue + - Fix test if legitimate failure + ``` + +### Example 6: Check commit status via Quay (real example) + +**User**: "Where is commit f3edcbc for osd-metrics-exporter?" + +**pdhelper Response**: +1. Check Quay for image availability: + ```bash + curl -s "https://quay.io/api/v1/repository/redhat-services-prod/openshift/osd-metrics-exporter/tag/" | jq '.tags[] | select(.name | startswith("f3edcbc"))' + ``` + +2. Result - Images found in Quay: + ``` + βœ… Konflux Build Status: SUCCESS + + Images built on Tue, 24 Mar 2026 14:11-14:13 UTC: + - quay.io/redhat-services-prod/openshift/osd-metrics-exporter:f3edcbc + - quay.io/redhat-services-prod/openshift/osd-metrics-exporter-e2e:f3edcbc + - quay.io/redhat-services-prod/openshift/osd-metrics-exporter-pko:f3edcbc + ``` + +3. Check saas file configuration: + ```bash + grep -A 5 "ref:" ../app-interface/data/services/osd-operators/cicd/saas/saas-osd-metrics-exporter-pko.yaml + ``` + +4. Deployment Status Analysis: + ``` + βœ… Integration (ome-pko-integration): + - Config: ref: main (watches quay for new images) + - Image: quay.io/.../osd-metrics-exporter-e2e:f3edcbc + - Status: DEPLOYED (auto-deployed when image became available) + - Deployed: March 24, 2026 + + βœ… Stage (ome-pko-stage): + - Config: ref: main (watches quay for new images) + - Image: quay.io/.../osd-metrics-exporter-e2e:f3edcbc + - Status: DEPLOYED (auto-deployed when image became available) + - Deployed: March 24, 2026 + + ❌ Production (OLM targets): + - Config: ref: 5933c1538c780d32561c5b3e352d03fba96e729d + - Status: NOT DEPLOYED (still on older commit) + - Action needed: Manual MR to update production refs to f3edcbc + + Next Steps for Production Deployment: + 1. Verify stage e2e gate success + 2. Create MR updating production target refs to f3edcbc + 3. Manual approval for canary targets + 4. Auto-rollout to remaining production hives (12h soak between phases) + ``` + +**Key Insight**: When saas targets use `ref: main`, checking Quay is the most reliable way to determine if a commit is deployed, since the saas file doesn't show specific commit SHAs. + +## Tools and Commands + +### Get latest commit from repository + +**IMPORTANT - Repository Lookup Order:** +When you need to check the latest commit for a component, always use this priority order: + +1. **First: Check for local clone in parent directory (`../`)** + ```bash + # Check if repository exists locally + if [ -d "../{component-name}" ]; then + cd ../{component-name} + git fetch origin + git log --format='%h|%ci|%s' origin/master -1 + cd - + fi + ``` + +2. **Second: Only if not found locally, clone to /tmp** + ```bash + # Only clone if no local copy exists + cd /tmp + git clone --depth 10 https://github.com/openshift/{component-name}.git + cd {component-name} + git log --format='%h|%ci|%s' origin/master -1 + ``` + +**Example workflow:** +```bash +# For route-monitor-operator, first check ../route-monitor-operator +# If not found, then clone to /tmp/route-monitor-operator +``` + +**Benefits of checking local clones first:** +- Faster - no network download needed +- Reduces GitHub API rate limiting +- Uses repositories already available on developer's machine +- Typical setup: osde2e/ and other repos are siblings in the same parent directory + +### Locate saas file for a repository +```bash +# For a repository like github.com/openshift/must-gather-operator +find ../app-interface/data -name "saas-must-gather-operator.yaml" +``` + +### Parse saas file and check image tags +```bash +# View the saas file +cat ../app-interface/data/services/osd-operators/cicd/saas/saas-must-gather-operator.yaml + +# Check which targets are watching which channels +grep -A 5 "subscribe:" ../app-interface/data/services/osd-operators/cicd/saas/saas-must-gather-operator.yaml +``` + +### Find hotfix versions in app.yaml +```bash +# Check current hotfix versions +grep -A 5 "hotfixVersions:" ../app-interface/data/services/osd-operators/must-gather-operator/app.yml +``` + +### Check Konflux build status via Quay +```bash +# Konflux builds are tied to commit SHAs and pushed to Quay +# Check if a commit has been built by searching Quay tags + +# Method 1: Check via Quay web UI +# Navigate to: https://quay.io/repository/redhat-services-prod/openshift/{component-name} +# Search for your commit SHA in the tags + +# Method 2: Check via Quay API +curl -s "https://quay.io/api/v1/repository/redhat-services-prod/openshift/{component-name}/tag/" | jq '.tags[] | select(.name | contains("f3edcbc")) | {name: .name, last_modified: .last_modified}' + +# Example for osd-metrics-exporter: +curl -s "https://quay.io/api/v1/repository/redhat-services-prod/openshift/osd-metrics-exporter/tag/" | jq '.tags[] | select(.name | contains("f3edcbc"))' + +# Check all related images (component may have multiple image repos): +# - {component-name} (main operator image) +# - {component-name}-e2e (e2e test image) +# - {component-name}-pko (Package Operator bundle) + +# Example for osd-metrics-exporter with commit f3edcbc: +curl -s "https://quay.io/api/v1/repository/redhat-services-prod/openshift/osd-metrics-exporter/tag/" | jq '.tags[] | select(.name | startswith("f3edcbc"))' +curl -s "https://quay.io/api/v1/repository/redhat-services-prod/openshift/osd-metrics-exporter-e2e/tag/" | jq '.tags[] | select(.name | startswith("f3edcbc"))' +curl -s "https://quay.io/api/v1/repository/redhat-services-prod/openshift/osd-metrics-exporter-pko/tag/" | jq '.tags[] | select(.name | startswith("f3edcbc"))' +``` + +### Determine deployment from Quay images +```bash +# If the commit tag exists in Quay and the saas file uses ref: main +# Then the commit is likely deployed to environments watching that image + +# Integration/Stage with ref: main β†’ Auto-deployed when image is available +# Production with specific ref β†’ Only deployed if ref matches the commit SHA +``` + +## Team Ownership Mapping + +Components are owned by the following teams. Use the repository name as the component name when querying. + +### Team Aurora +- aws-account-operator +- aws-vpce-operator +- boilerplate +- cloud-ingress-operator +- custom-domains-operator +- gcp-project-operator +- osd-aws-privatelink-terraform-hypershift +- osd-network-verifier +- osd-network-verifier-golden-ami +- osd-privatelink-terraform-classic +- rosa-srep-zero-egress +- terraform-aws-s3-bootstrap +- terraform-aws-vpc-private + +### Team Thor +- aws-jumpaccounts-terraform +- aws-payer-accounts-terraform +- backplane-api +- backplane-cli +- dedicated-admin-operator +- managed-cluster-validating-webhooks +- rbac-permissions-operator +- sre-platform-rhcontrol-terraform + +### Team Hulk +- certman-operator +- managed-cluster-config +- managed-node-metadata-operator +- managed-upgrade-operator +- managed-velero-operator +- must-gather-operator +- ocm-agent +- ocm-agent-operator + +### Team Security +- clamav-images +- ids-images +- splunk-audit-exporter +- splunk-forwarder-images +- splunk-forwarder-operator + +### Team Orange +- configuration-anomaly-detection +- managed-scripts +- ocm-container +- osdctl +- srep-network-toolbox +- backplane-tools + +### Team Rocket +- configure-alertmanager-operator +- deadmanssnitch-operator +- dynatrace-config +- hypershift-dataplane-metrics-forwarder +- hypershift-platform-rhobs-rules +- osd-cluster-ready +- osd-rhobs-rules-and-dashboards +- pagerduty-operator +- route-monitor-operator +- osd-metrics-exporter + +### Team LPSRE +- package-operator + +## Repository Mapping + +Common OpenShift repositories and their app-interface locations: + +| GitHub Repository | Service Name | Saas File Location | E2E Gate Jobs | App File Location | +|-------------------|--------------|----------------------------------------------------------------------|---------------|-------------------| +| openshift/osd-example-operator | osd-operators | services/osd-operators/cicd/saas/saas-osd-example-operator*.yaml | services/osd-operators/cicd/saas/saas-osd-example-operator/osde2e-focus-test.yaml | services/osd-operators/osd-example-operator/app.yml | +| openshift/must-gather-operator | osd-operators | services/osd-operators/cicd/saas/saas-must-gather-operator*.yaml | services/osd-operators/cicd/saas/saas-must-gather-operator/osde2e-focus-test.yaml | services/osd-operators/must-gather-operator/app.yml | +| openshift/managed-upgrade-operator | osd-operators | services/osd-operators/cicd/saas/saas-managed-upgrade-operator*.yaml | services/osd-operators/cicd/saas/saas-managed-upgrade-operator/osde2e-focus-test.yaml | services/osd-operators/managed-upgrade-operator/app.yml | + +Pattern: +- Saas file: `services/{service-name}/cicd/saas/saas-{operator-name}*.yaml` +- E2E gate jobs: `services/{service-name}/cicd/saas/saas-{operator-name}/osde2e-focus-test.yaml` +- App file: `services/{service-name}/{operator-name}/app.yml`