| name | nova-triage |
| description | Fetch a Nova Launchpad bug, validate against source code, and classify its validity. Use when triaging a Launchpad bug report to determine if it is a genuine defect, configuration issue, or feature request. |
Triage a Nova Launchpad Bug
Fetch bug details from Launchpad, display a structured summary, analyze the report against the Nova source checkout, and classify whether the bug is valid or falls into an invalid category.
Agent Collaboration: Invoke shared agent personas for specialized triage analysis:
- @bug-triager.md — Invoke for every triage to apply systematic validity classification and Launchpad lifecycle knowledge
- @openstack-operator.md — Invoke when the bug report suggests a configuration or deployment issue (misconfiguration signals, operator-provided logs, upgrade-related symptoms)
- @nova-coresec.md — Invoke when the bug has
"security_related": true or describes potential security vulnerabilities
Input
A Launchpad bug ID (integer) or full URL.
Examples:
/nova-triage 2112373/nova-triage https://bugs.launchpad.net/nova/+bug/2112373
Process
Step 1. Parse Input
Extract the numeric bug ID from the user's input:
- If a bare integer, use it directly
- If a Launchpad URL (e.g.,
https://bugs.launchpad.net/nova/+bug/2112373), extract the numeric ID
- If the format is unrecognized, report an error with the expected formats
Step 2. Ensure Nova Source Checkout
Check that the Nova source checkout exists at /workspace/repos/nova/.
If missing, automatically clone it:
git clone https://opendev.org/openstack/nova.git /workspace/repos/nova
Inform the user that cloning is in progress — this may take a few minutes.
Step 3. Fetch Bug from Launchpad
Run workflows/shared/scripts/launchpad-fetch-bug.sh {bug_id} and parse the JSON output.
Handle errors:
- Bug not found (exit code 1): report "Bug {id} not found on Launchpad"
- Private bug (
"private": true): warn "This bug is private. Triage details should not be shared publicly." Ask user whether to proceed.
- Not a Nova bug (
"is_nova": false): warn "This bug is not filed against Nova. It targets: {projects}." Ask user whether to proceed anyway.
Step 4. Display Structured Summary
Present the bug details in a readable format:
Bug #{id}: {title}
- URL: {web_link}
- Reporter: {reporter}
- Filed: {date_created}
- Last Updated: {date_updated}
- Status: {status}
- Importance: {importance}
- Tags: {tags}
- Private: {yes/no}
Description:
{description — truncate to first 2000 characters if very long, note if truncated}
Recent Comments ({message_count} total):
Show the last 5 comments summarized (author, date, first ~200 characters of content)
Step 5. Analyze Validity Against Nova Source
For each validity category, check the relevant indicators using the Nova source checkout at /workspace/repos/nova/:
Configuration Issue:
- Search
nova/conf/ for config options mentioned in the bug report (option names, section names, error messages referencing config)
- Check if the described behavior matches a known misconfiguration pattern
- Look for
oslo.config option registrations (cfg.StrOpt, cfg.IntOpt, etc.) related to the issue
- Check
nova/conf/ files for deprecated options that may have changed behavior
Unsupported Feature:
- Check if the described deployment, driver, or feature is in Nova's supported set
- Search for capability flags in virt drivers (
nova/virt/)
- Check API extension registrations and microversion boundaries
- Look for feature gates or config options that enable/disable the feature
Incomplete Report:
- Check if the bug includes: Nova version, steps to reproduce, logs or tracebacks, configuration details, deployment topology
- For each missing element, prepare a specific question for the reporter
- Common missing info: "What Nova version?", "What hypervisor/virt driver?", "Can you provide nova-compute logs?", "What's in your nova.conf for [section]?"
Not Reproducible in Master:
- Search
git log in the Nova checkout for commits mentioning the bug ID, related keywords, or affecting the code path
- Check if the referenced code paths have been significantly changed or refactored
- Look for
Closes-Bug or Related-Bug references in recent commits
- Compare the reported behavior against the current master code
RFE (Request for Enhancement):
- Check if the functionality the reporter expects actually exists in the codebase
- If the reporter assumes a feature exists but the code path is not implemented, this is an RFE
- Example: expecting flavor extra specs for image properties that have no corresponding handler in Nova
- Verify by searching for the expected implementation (API endpoints, object attributes, config options) and confirming they don't exist
Likely Valid Bug:
- If none of the above categories apply, the issue appears to be a genuine defect
- Identify the affected Nova subsystem (compute, scheduler, API, conductor, libvirt, cells, etc.)
- Propose an importance level based on impact:
- Critical: data loss, regression, blocks upgrades
- High: crashes, deadlocks, security implications
- Medium: incorrect behavior with workaround
- Low: edge case, cosmetic, trivial workaround
Step 5b. Check for Duplicates
- Extract key terms from the bug title and description (3-5 distinctive keywords)
- Search Launchpad for Nova bugs with similar characteristics using
curl against https://api.launchpad.net/1.0/nova?ws.op=searchTasks&search_text={keywords}&status=New&status=Confirmed&status=Triaged&status=In+Progress&omit_duplicates=true
- For each candidate (max 5), assess similarity:
- Title similarity
- Matching tags
- Affected subsystem overlap
- Present ranked candidates with: bug ID, title, status, Launchpad URL, brief explanation of match
- If no strong candidates found, report: "No duplicate candidates identified."
Step 6. Present Classification
Present the triage result clearly:
Validity Assessment: {category}
Rationale: {1-3 sentences citing specific evidence from the bug report AND the Nova source checkout}
Proposed Launchpad Changes:
- Status: {current} → {proposed} (mapping: Configuration Issue → Invalid, Unsupported Feature → Won't Fix, Incomplete Report → Incomplete, Not Reproducible in Master → Invalid, RFE → Invalid, Likely Valid Bug → Triaged/Confirmed)
- Importance: {current} → {proposed} (for RFE: Wishlist; for Likely Valid Bug: proposed level; others: unchanged)
Affected Subsystem: {subsystem name}
Confidence: {High/Medium/Low}
Duplicate Candidates: {list or "None identified"}
Source References: {file paths and line numbers examined in the Nova checkout}
If Incomplete Report: also show Questions for Reporter with the specific information needed.
If RFE: also note Recommendation: "Consider filing a nova-spec or RFE for this feature request."
Step 7. Await User Review
Present the classification for the triager's review. Do not proceed to any external action.
Offer next steps:
/nova-reproduce — deeper source analysis to verify reproducibility/nova-report — generate a persistent triage report artifact/nova-update-launchpad — post the triage findings to Launchpad
Output
The triage classification is held in session memory for use by /nova-reproduce, /nova-report, and /nova-update-launchpad.
No artifact is written by this skill — use /nova-report to generate a persistent artifact.
Writing Style
Follow the rules in rules.md. In particular:
- Lead with the classification and a one-sentence rationale
- Cite specific file paths and line numbers from the Nova checkout
- Be constructive — suggest fixes for configuration issues, list specific questions for incomplete reports
- Keep the summary scannable — busy triagers should understand the verdict in seconds
