-
Notifications
You must be signed in to change notification settings - Fork 57
CNV-74189: Lightspeed mcp integration document #3426
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?
CNV-74189: Lightspeed mcp integration document #3426
Conversation
|
@galkremer1: This pull request references CNV-74189 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 story to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: galkremer1 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
📝 WalkthroughWalkthroughA new comprehensive documentation file is added outlining the integration strategy for OpenShift Lightspeed with Model Context Protocol (MCP) for CNV UI. The document covers architecture, phased implementation, deployment options, code samples, and roadmap. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
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. Comment |
|
@galkremer1: This pull request references CNV-74189 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 story to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
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.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@LIGHTSPEED_MCP_INTEGRATION.md`:
- Around line 99-112: The Table of Contents contains two incorrect anchor
fragments: replace the fragment "#️-important-current-status--open-questions"
used for the first entry with "#️-critical-questions-blockers" to match the
actual header, and replace "#comparison-lightspeed-vs-direct-mcp" with
"#comparison-lightspeed-vs-direct-mcp-vs-alternative-approaches" for the
comparison entry so the TOC links match the headers; update the two TOC lines
accordingly (referencing the exact TOC entries shown and the target header
fragments).
- Around line 705-710: The withinTimeRange(vm, range) function currently uses
parseInt(range) and always treats the result as hours; update it to parse an
optional suffix (e.g., "h" for hours, "d" for days, "m" for minutes) from the
range string and convert the value to milliseconds accordingly before comparing
against now - created; implement fallback to hours for plain numbers and handle
invalid inputs safely (e.g., treat as 0 or return false). Ensure you update the
logic in withinTimeRange to compute a proper milliseconds threshold based on the
parsed unit and use vm.metadata.creationTimestamp as before.
🧹 Nitpick comments (3)
LIGHTSPEED_MCP_INTEGRATION.md (3)
601-630: Consider adding input validation for the search query.The
AISearchBarcomponent would benefit from validating that the query is not empty before triggering the search. This prevents unnecessary AI requests and improves UX.Optional improvement: Add query validation
const handleSearch = () => { + if (!query.trim()) return; + // Create prompt for Lightspeed with search context const prompt = `Search for virtual machines: ${query}. Use the search_virtual_machines tool to find matching VMs. Return results as a structured list.`; setSearchPrompt(prompt); };
1122-1141: Add error handling and reconsider namespace defaults.The
k8sClientmethods lack error handling, which could lead to uncaught exceptions. Additionally, defaulting to['default']namespace when none specified may not match user expectations for a cluster-wide search.Recommended improvements
1. Add error handling:
async listVirtualMachines({ namespaces, labelSelector }) { const results = []; + const errors = []; for (const ns of namespaces || ['default']) { - const response = await customApi.listNamespacedCustomObject( - 'kubevirt.io', - 'v1', - ns, - 'virtualmachines', - undefined, - undefined, - undefined, - undefined, - labelSelector, - ); - results.push(...response.body.items); + try { + const response = await customApi.listNamespacedCustomObject( + 'kubevirt.io', + 'v1', + ns, + 'virtualmachines', + undefined, + undefined, + undefined, + undefined, + labelSelector, + ); + results.push(...response.body.items); + } catch (error) { + errors.push({ namespace: ns, error: error.message }); + } } - return { items: results }; + return { items: results, errors }; },2. Consider namespace handling:
- For user queries, respect RBAC and list VMs only in namespaces the user can access
- Document that
namespacesparameter is required for security reasons- Alternatively, implement namespace discovery based on user permissions
186-209: Add language identifier to code block for better rendering.The architecture diagram code block (lines 186-209) is missing a language identifier, which prevents proper syntax highlighting and may affect rendering in some Markdown viewers.
Minor formatting improvement
Add
textorplaintextafter the opening triple backticks:-``` +```text ┌─────────────────┐ ┌──────────────────┐ ┌──────────────────────┐ │ CNV UI │────────►│ Lightspeed │────────►│ openshift-mcp-server │ ...This applies to other diagram blocks at lines 420, 580, and 1042 as well.
| ## Table of Contents | ||
|
|
||
| 1. [Important: Current Status & Open Questions](#️-important-current-status--open-questions) | ||
| 2. [Current State: Existing Lightspeed Integration](#current-state-existing-lightspeed-integration) | ||
| 3. [What Changed: Lightspeed Now Supports MCP](#what-changed-lightspeed-now-supports-mcp) | ||
| 4. [Architecture Overview](#architecture-overview) | ||
| 5. [Implementation Strategy](#implementation-strategy) | ||
| 6. [Use Case Implementation](#use-case-implementation) | ||
| 7. [Technical Details](#technical-details) | ||
| 8. [Deployment](#deployment) | ||
| 9. [Comparison: Lightspeed vs Direct MCP](#comparison-lightspeed-vs-direct-mcp) | ||
| 10. [Recommendations](#recommendations) | ||
| 11. [Next Steps](#next-steps) | ||
|
|
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.
Fix broken link fragments in Table of Contents.
The Table of Contents has two broken link references that don't match the actual section headers:
- Line 101:
#️-important-current-status--open-questionsshould be#️-critical-questions-blockers(to match line 71) - Line 109:
#comparison-lightspeed-vs-direct-mcpshould be#comparison-lightspeed-vs-direct-mcp-vs-alternative-approaches(to match line 1727)
🔗 Proposed fixes
-1. [Important: Current Status & Open Questions](#️-important-current-status--open-questions)
+1. [Important: Current Status & Open Questions](#️-critical-questions-blockers)
2. [Current State: Existing Lightspeed Integration](`#current-state-existing-lightspeed-integration`)
3. [What Changed: Lightspeed Now Supports MCP](`#what-changed-lightspeed-now-supports-mcp`)
4. [Architecture Overview](`#architecture-overview`)
5. [Implementation Strategy](`#implementation-strategy`)
6. [Use Case Implementation](`#use-case-implementation`)
7. [Technical Details](`#technical-details`)
8. [Deployment](`#deployment`)
-9. [Comparison: Lightspeed vs Direct MCP](`#comparison-lightspeed-vs-direct-mcp`)
+9. [Comparison: Lightspeed vs Direct MCP](`#comparison-lightspeed-vs-direct-mcp-vs-alternative-approaches`)
10. [Recommendations](`#recommendations`)
11. [Next Steps](`#next-steps`)🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 101-101: Link fragments should be valid
(MD051, link-fragments)
[warning] 109-109: Link fragments should be valid
(MD051, link-fragments)
🤖 Prompt for AI Agents
In `@LIGHTSPEED_MCP_INTEGRATION.md` around lines 99 - 112, The Table of Contents
contains two incorrect anchor fragments: replace the fragment
"#️-important-current-status--open-questions" used for the first entry with
"#️-critical-questions-blockers" to match the actual header, and replace
"#comparison-lightspeed-vs-direct-mcp" with
"#comparison-lightspeed-vs-direct-mcp-vs-alternative-approaches" for the
comparison entry so the TOC links match the headers; update the two TOC lines
accordingly (referencing the exact TOC entries shown and the target header
fragments).
| function withinTimeRange(vm, range) { | ||
| const created = new Date(vm.metadata.creationTimestamp); | ||
| const now = new Date(); | ||
| const hours = parseInt(range); | ||
| return now - created < hours * 60 * 60 * 1000; | ||
| } |
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.
Fix time range parsing to handle suffixes.
The withinTimeRange function uses parseInt(range) which will extract only the numeric part from strings like "1h" or "7d", but the calculation assumes the value is in hours. This will fail for day-based ranges.
🐛 Proposed fix for time range parsing
function withinTimeRange(vm, range) {
const created = new Date(vm.metadata.creationTimestamp);
const now = new Date();
- const hours = parseInt(range);
- return now - created < hours * 60 * 60 * 1000;
+
+ // Parse range like "1h", "24h", "7d"
+ const match = range.match(/^(\d+)([hd])$/);
+ if (!match) return true; // Invalid format, include by default
+
+ const value = parseInt(match[1]);
+ const unit = match[2];
+ const milliseconds = unit === 'h'
+ ? value * 60 * 60 * 1000
+ : value * 24 * 60 * 60 * 1000;
+
+ return now - created < milliseconds;
}🤖 Prompt for AI Agents
In `@LIGHTSPEED_MCP_INTEGRATION.md` around lines 705 - 710, The
withinTimeRange(vm, range) function currently uses parseInt(range) and always
treats the result as hours; update it to parse an optional suffix (e.g., "h" for
hours, "d" for days, "m" for minutes) from the range string and convert the
value to milliseconds accordingly before comparing against now - created;
implement fallback to hours for plain numbers and handle invalid inputs safely
(e.g., treat as 0 or return false). Ensure you update the logic in
withinTimeRange to compute a proper milliseconds threshold based on the parsed
unit and use vm.metadata.creationTimestamp as before.
33d51ce to
a93da56
Compare
a93da56 to
0b0af01
Compare
📝 Description
This is a PR for keeping track of the integration document for CNV-74189
Summary by CodeRabbit