CORENET-7134: Add ovn-kubernetes toolset skeleton#315
Conversation
|
@mattedallo: This pull request references CORENET-7134 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 "5.0.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. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (19)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (15)
📝 WalkthroughWalkthroughThis PR adds the OVN-Kubernetes MCP toolset, registers it for loading, expands MCP test coverage, and adds OVN-Kubernetes eval tasks and setup scripts. ChangesOVN-Kubernetes Toolset and Integration
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: mattedallo 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 |
|
/test all |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
| @@ -0,0 +1,38 @@ | |||
| package ovnkubernetes | |||
There was a problem hiding this comment.
seems pretty empty
why not land this with actual tools (e.g. as go module)?
There was a problem hiding this comment.
Hi @matzew, thanks for reviewing!
Yep, we have a followup PRs coming for the tools.
But If you prefer I may add some of them into this PR directly.
There was a problem hiding this comment.
yes - I'd think we do not land empty toolsets here
There was a problem hiding this comment.
+1 let's at least try to land the first tool in this PR. If you want to then incrementally add some more tools in future PRs that is cool
There was a problem hiding this comment.
Hi @matzew and @Cali0707, While adding the tools I am considering this approach:
the upstream exports tool definitions using gosdk.Tool from the go-sdk (a type both repos already depend on), paired with a type-erased execution function. In here we just iterates and converts (From gosdk.Tool to api.Tool) , no manual schema duplication. When upstream adds a new tool, downstream would have the tool automatically with version bump.
The benefit is that we don't duplicate the schema definition and we get the new tools automatically with version bump.
Is this something desired or you see problems with this approach?
|
@mattedallo also, if this new toolset is directly mapping to "upstream" ovn-k8s, I think the right address for PRs like that might be the actual upstream repo. Here, on OCP downstream, we might want to have mostly OCP specifics. That said, see recent discussion on #122 that for some CRUD tools, it might be also just fine to provide evals and see if those are passing already w/ our |
Hey @matzew, one of the reasons not to add these tools to upstream is because some of the ovnk tools need the node-debug functionality and as per some existing conversations it seems that adding that tool upstream is not in current plans. Additionally, upstream k8s-mcp-server might want to be CNI agnostic whereas for openshift-mcp-server these tools will be very useful as most customers use ovnk as the CNI. We already have a separate upstream repo for ovnk mcp server (https://github.com/ovn-kubernetes/ovn-kubernetes-mcp) and thus adding these tools in k8s-mcp-server will mean that 2 separate upstream projects have the same tools, which probably is not ideal. I have created an EP (openshift/enhancements#2002) where we can have further discussions on this topic. PTAL. |
1124f8a to
39da71e
Compare
39da71e to
b430132
Compare
Register an empty ovn-kubernetes toolset so sibling stories (CORENET-7135/7136) can land OVN/OVS tool handlers on top of this framework. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Matteo Dallaglio <mdallagl@redhat.com>
Import the ovn-kubernetes-mcp library which provides OVN network analysis tools (show, get, lflow-list, trace) as an MCP server. Signed-off-by: Matteo Dallaglio <mdallagl@redhat.com>
Add 4 OVN troubleshooting tools to the ovn-kubernetes toolset: ovn_show, ovn_get, ovn_lflow_list, ovn_trace. Each tool is defined explicitly with its own InputSchema, handler, and annotations. Handlers are thin wrappers that call upstream ovn-kubernetes-mcp methods directly. Signed-off-by: Matteo Dallaglio <mdallagl@redhat.com>
a5b89b1 to
61cd5d3
Compare
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@evals/tasks/ovn-kubernetes/ovn-get/ovn-get-switch-with-columns.yaml`:
- Line 23: The judge reasoning text contains a typo in the Logical_Switch output
description; update the wording in the evaluation YAML so “speceific” is
corrected to “specific” in the reasoning string used by
ovn-get-switch-with-columns, keeping the eval text clear and unambiguous.
In
`@evals/tasks/ovn-kubernetes/ovn-lflow-list/ovn-lflow-list-datapath-with-pattern.yaml`:
- Line 25: Fix the typo in the expected-output text for the ovn-lflow-list
datapath pattern by updating the string containing “Comprisd” to the correct
spelling “Comprised”; locate the affected expected text in the YAML entry and
adjust only that literal so the validation matches the intended output.
In `@evals/tasks/ovn-kubernetes/ovn-lflow-list/setup.sh`:
- Around line 4-7: The setup check in the pod lookup currently relies on
grepping human-readable kubectl output, which is brittle. Update the
ovnkube-node readiness check in setup.sh to use kubectl’s machine-readable
filtering with a field selector for Running pods and output names directly, then
keep the existing failure path if no pod names are returned. Use the existing
pod query block as the place to switch from grep-based matching to direct status
filtering.
In `@evals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-detailed.yaml`:
- Line 48: The ovn-trace-detailed.yaml task uses mutable container image tags,
which can make evals drift and fail nondeterministically. Replace the `image`
values in the affected task entries with pinned references using a fixed tag or
digest instead of `:latest`, and update both occurrences noted in the comment so
the task always pulls the same container version.
In `@evals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-with-pattern.yaml`:
- Line 85: The prompt in the ovn-trace task has conflicting filter instructions,
so make the wording consistent across the affected steps. Update the task
description and the later pattern assignment in the ovn-trace-with-pattern YAML
so both reference the same output filter, using the unique prompt text and
pattern field together to avoid ambiguity in the expected behavior.
In `@go.mod`:
- Line 74: Upgrade the containerd dependency to remove the affected version:
update the github.com/containerd/containerd entry in go.mod to v1.7.33 or newer,
then refresh the vendored dependencies so the lockstep module set matches the
new version. Make sure any references in the module graph that resolve through
containerd are also updated consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 593624a7-cd41-44bc-91da-1c4860509d7b
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (25)
evals/claude-code/eval.yamlevals/gemini-agent/eval.yamlevals/openai-agent/eval.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-list-logical-routers.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-pattern-with-columns.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-southbound-chassis.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-specific-router.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-switch-with-columns.yamlevals/tasks/ovn-kubernetes/ovn-get/setup.shevals/tasks/ovn-kubernetes/ovn-lflow-list/ovn-lflow-list-datapath-with-pattern.yamlevals/tasks/ovn-kubernetes/ovn-lflow-list/ovn-lflow-list-for-datapath.yamlevals/tasks/ovn-kubernetes/ovn-lflow-list/setup.shevals/tasks/ovn-kubernetes/ovn-show/ovn-show-northbound.yamlevals/tasks/ovn-kubernetes/ovn-show/ovn-show-southbound.yamlevals/tasks/ovn-kubernetes/ovn-show/setup.shevals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-detailed.yamlevals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-summary.yamlevals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-with-pattern.yamlgo.modpkg/mcp/modules.gopkg/mcp/ovn_kubernetes_test.gopkg/mcp/testdata/toolsets-ovn-kubernetes-tools.jsonpkg/mcp/toolsets_test.gopkg/toolsets/ovnkubernetes/ovn.gopkg/toolsets/ovnkubernetes/toolset.go
💤 Files with no reviewable changes (2)
- pkg/toolsets/ovnkubernetes/toolset.go
- pkg/toolsets/ovnkubernetes/ovn.go
✅ Files skipped from review due to trivial changes (4)
- evals/tasks/ovn-kubernetes/ovn-get/ovn-get-pattern-with-columns.yaml
- evals/claude-code/eval.yaml
- evals/tasks/ovn-kubernetes/ovn-get/ovn-get-specific-router.yaml
- evals/tasks/ovn-kubernetes/ovn-get/ovn-get-southbound-chassis.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
- pkg/mcp/modules.go
- pkg/mcp/toolsets_test.go
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@evals/tasks/ovn-kubernetes/ovn-get/ovn-get-switch-with-columns.yaml`:
- Line 23: The judge reasoning text contains a typo in the Logical_Switch output
description; update the wording in the evaluation YAML so “speceific” is
corrected to “specific” in the reasoning string used by
ovn-get-switch-with-columns, keeping the eval text clear and unambiguous.
In
`@evals/tasks/ovn-kubernetes/ovn-lflow-list/ovn-lflow-list-datapath-with-pattern.yaml`:
- Line 25: Fix the typo in the expected-output text for the ovn-lflow-list
datapath pattern by updating the string containing “Comprisd” to the correct
spelling “Comprised”; locate the affected expected text in the YAML entry and
adjust only that literal so the validation matches the intended output.
In `@evals/tasks/ovn-kubernetes/ovn-lflow-list/setup.sh`:
- Around line 4-7: The setup check in the pod lookup currently relies on
grepping human-readable kubectl output, which is brittle. Update the
ovnkube-node readiness check in setup.sh to use kubectl’s machine-readable
filtering with a field selector for Running pods and output names directly, then
keep the existing failure path if no pod names are returned. Use the existing
pod query block as the place to switch from grep-based matching to direct status
filtering.
In `@evals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-detailed.yaml`:
- Line 48: The ovn-trace-detailed.yaml task uses mutable container image tags,
which can make evals drift and fail nondeterministically. Replace the `image`
values in the affected task entries with pinned references using a fixed tag or
digest instead of `:latest`, and update both occurrences noted in the comment so
the task always pulls the same container version.
In `@evals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-with-pattern.yaml`:
- Line 85: The prompt in the ovn-trace task has conflicting filter instructions,
so make the wording consistent across the affected steps. Update the task
description and the later pattern assignment in the ovn-trace-with-pattern YAML
so both reference the same output filter, using the unique prompt text and
pattern field together to avoid ambiguity in the expected behavior.
In `@go.mod`:
- Line 74: Upgrade the containerd dependency to remove the affected version:
update the github.com/containerd/containerd entry in go.mod to v1.7.33 or newer,
then refresh the vendored dependencies so the lockstep module set matches the
new version. Make sure any references in the module graph that resolve through
containerd are also updated consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 593624a7-cd41-44bc-91da-1c4860509d7b
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (25)
evals/claude-code/eval.yamlevals/gemini-agent/eval.yamlevals/openai-agent/eval.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-list-logical-routers.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-pattern-with-columns.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-southbound-chassis.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-specific-router.yamlevals/tasks/ovn-kubernetes/ovn-get/ovn-get-switch-with-columns.yamlevals/tasks/ovn-kubernetes/ovn-get/setup.shevals/tasks/ovn-kubernetes/ovn-lflow-list/ovn-lflow-list-datapath-with-pattern.yamlevals/tasks/ovn-kubernetes/ovn-lflow-list/ovn-lflow-list-for-datapath.yamlevals/tasks/ovn-kubernetes/ovn-lflow-list/setup.shevals/tasks/ovn-kubernetes/ovn-show/ovn-show-northbound.yamlevals/tasks/ovn-kubernetes/ovn-show/ovn-show-southbound.yamlevals/tasks/ovn-kubernetes/ovn-show/setup.shevals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-detailed.yamlevals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-summary.yamlevals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-with-pattern.yamlgo.modpkg/mcp/modules.gopkg/mcp/ovn_kubernetes_test.gopkg/mcp/testdata/toolsets-ovn-kubernetes-tools.jsonpkg/mcp/toolsets_test.gopkg/toolsets/ovnkubernetes/ovn.gopkg/toolsets/ovnkubernetes/toolset.go
💤 Files with no reviewable changes (2)
- pkg/toolsets/ovnkubernetes/toolset.go
- pkg/toolsets/ovnkubernetes/ovn.go
✅ Files skipped from review due to trivial changes (4)
- evals/tasks/ovn-kubernetes/ovn-get/ovn-get-pattern-with-columns.yaml
- evals/claude-code/eval.yaml
- evals/tasks/ovn-kubernetes/ovn-get/ovn-get-specific-router.yaml
- evals/tasks/ovn-kubernetes/ovn-get/ovn-get-southbound-chassis.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
- pkg/mcp/modules.go
- pkg/mcp/toolsets_test.go
🛑 Comments failed to post (6)
evals/tasks/ovn-kubernetes/ovn-get/ovn-get-switch-with-columns.yaml (1)
23-23: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix typo in judge reasoning text.
Line 23 has “speceific”; use “specific” to keep eval text clean and unambiguous.
Suggested patch
- reasoning: "Output should show Logical_Switch entries with name and ports columns including join, transit, and node speceific switches" + reasoning: "Output should show Logical_Switch entries with name and ports columns including join, transit, and node specific switches"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.reasoning: "Output should show Logical_Switch entries with name and ports columns including join, transit, and node specific switches"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@evals/tasks/ovn-kubernetes/ovn-get/ovn-get-switch-with-columns.yaml` at line 23, The judge reasoning text contains a typo in the Logical_Switch output description; update the wording in the evaluation YAML so “speceific” is corrected to “specific” in the reasoning string used by ovn-get-switch-with-columns, keeping the eval text clear and unambiguous.evals/tasks/ovn-kubernetes/ovn-lflow-list/ovn-lflow-list-datapath-with-pattern.yaml (1)
25-25: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Correct typo in expected-output text.
Line 25 has “Comprisd”; replace with “Comprised”.
Suggested patch
- contains: "Comprisd of routing information from ovn_cluster_router to upstream or downstream switches" + contains: "Comprised of routing information from ovn_cluster_router to upstream or downstream switches"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.contains: "Comprised of routing information from ovn_cluster_router to upstream or downstream switches"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@evals/tasks/ovn-kubernetes/ovn-lflow-list/ovn-lflow-list-datapath-with-pattern.yaml` at line 25, Fix the typo in the expected-output text for the ovn-lflow-list datapath pattern by updating the string containing “Comprisd” to the correct spelling “Comprised”; locate the affected expected text in the YAML entry and adjust only that literal so the validation matches the intended output.evals/tasks/ovn-kubernetes/ovn-lflow-list/setup.sh (1)
4-7: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
Use machine-readable pod status filtering for setup checks.
Grepping table output is fragile. Query running pods directly (
--field-selector+-o name) to avoid format-dependent false negatives.Suggested diff
-kubectl get pods -n openshift-ovn-kubernetes -l app=ovnkube-node | grep Running || { +kubectl get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \ + --field-selector=status.phase=Running -o name | grep -q . || { echo "ERROR: No running ovnkube-node pods found" exit 1 }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.kubectl get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \ --field-selector=status.phase=Running -o name | grep -q . || { echo "ERROR: No running ovnkube-node pods found" exit 1 }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@evals/tasks/ovn-kubernetes/ovn-lflow-list/setup.sh` around lines 4 - 7, The setup check in the pod lookup currently relies on grepping human-readable kubectl output, which is brittle. Update the ovnkube-node readiness check in setup.sh to use kubectl’s machine-readable filtering with a field selector for Running pods and output names directly, then keep the existing failure path if no pod names are returned. Use the existing pod query block as the place to switch from grep-based matching to direct status filtering.evals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-detailed.yaml (1)
48-48: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Pin container images instead of using
:latest.Mutable tags make eval behavior drift over time and can cause nondeterministic failures. Use a fixed tag or digest.
Also applies to: 62-62
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@evals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-detailed.yaml` at line 48, The ovn-trace-detailed.yaml task uses mutable container image tags, which can make evals drift and fail nondeterministically. Replace the `image` values in the affected task entries with pinned references using a fixed tag or digest instead of `:latest`, and update both occurrences noted in the comment so the task always pulls the same container version.evals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-with-pattern.yaml (1)
85-85: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Fix contradictory filtering instructions in the prompt.
The task says to filter for lines containing
"output"but later instructspattern="acl". Keep these consistent so the expected behavior is unambiguous.Suggested fix
- Trace a TCP packet from source-pod to dest-pod in namespace ovn-trace-test and filter output to show only lines containing "output". + Trace a TCP packet from source-pod to dest-pod in namespace ovn-trace-test and filter output to show only lines containing "acl".Also applies to: 95-95
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@evals/tasks/ovn-kubernetes/ovn-trace/ovn-trace-with-pattern.yaml` at line 85, The prompt in the ovn-trace task has conflicting filter instructions, so make the wording consistent across the affected steps. Update the task description and the later pattern assignment in the ovn-trace-with-pattern YAML so both reference the same output filter, using the unique prompt text and pattern field together to avoid ambiguity in the expected behavior.go.mod (1)
74-74: 🔒 Security & Privacy | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
sed -n '60,90p' go.modRepository: openshift/openshift-mcp-server
Length of output: 1834
🏁 Script executed:
sed -n '60,90p' go.modRepository: openshift/openshift-mcp-server
Length of output: 1834
🌐 Web query:
containerd v1.7.32 advisories fixed release CRI logger path DoS host-root command execution💡 Result:
Containerd v1.7.32 was released on May 20, 2026, primarily to address a security vulnerability regarding user ID handling [1][2]. Regarding the specific concerns mentioned in your query: 1. User ID Handling Bypass (Fixed in v1.7.32): CVE-2026-46680 affects containerd versions >= 1.7.27 and < 1.7.32 [2][3]. It involves an issue where a numeric User directive in a container configuration that cannot be parsed as a 32-bit integer is incorrectly treated as a username. If a malicious image provides an /etc/passwd file mapping this value to UID 0 (root), it can bypass Kubernetes runAsNonRoot restrictions and allow the container to run as root [2][4]. This was fixed in v1.7.32 [2][3]. 2. Host-Root Command Execution & Denial of Service (DoS): Recent advisories have identified vulnerabilities affecting versions up to v1.7.32 (inclusive), which were subsequently fixed in v1.7.33: - Host-Root Command Execution (CVE-2026-53488): The CRI plugin incorrectly propagates LABEL instructions from image configs without validation. This can lead to arbitrary command execution on the host when using certain binary loggers [5][6]. - Runtime Denial of Service (CVE-2026-47262): A maliciously crafted image can cause memory exhaustion, leading to an Out Of Memory (OOM) kill of the containerd process, rendering the runtime API unavailable [7]. 3. Arbitrary Log File Read: CVE-2026-53489 involves a path traversal/symlink vulnerability in the CRI plugin when restoring container.log from a checkpoint, which could allow unauthorized reading of arbitrary host files [8][9]. This is also fixed in v1.7.33 [8][10]. In summary, while v1.7.32 fixed the runAsNonRoot bypass (CVE-2026-46680), it remains vulnerable to the host-root command execution, runtime DoS, and arbitrary log file read vulnerabilities mentioned, which require updating to v1.7.33 or later [5][7][8][2].
Citations:
- 1: https://github.com/containerd/containerd/releases/tag/v1.7.32
- 2: GHSA-fqw6-gf59-qr4w
- 3: https://scout.docker.com/vulnerabilities/id/CVE-2026-46680?n=containerd&ns=github.com%2Fcontainerd&s=github&t=golang&vr=%3E%3D1.7.27%2C%3C1.7.32
- 4: https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMCONTAINERDCONTAINERDOCI-16795347
- 5: GHSA-xhf5-7wjv-pqxp
- 6: https://advisories.ecosyste.ms/advisories/GSA_kwCzR0hTQS14aGY1LTd3anYtcHF4cM4ABZLf
- 7: GHSA-jpcc-p29g-p8mq
- 8: GHSA-rgh6-rfwx-v388
- 9: https://advisories.gitlab.com/golang/github.com/containerd/containerd/v2/CVE-2026-53489/
- 10: https://advisories.ecosyste.ms/advisories/GSA_kwCzR0hTQS1yZ2g2LXJmd3gtdjM4OM4ABZLg
🏁 Script executed:
rg -n "github\.com/containerd/containerd|containerd/" -S .Repository: openshift/openshift-mcp-server
Length of output: 16658
🏁 Script executed:
rg -n "github\.com/containerd/containerd|containerd/" -S .Repository: openshift/openshift-mcp-server
Length of output: 16658
Upgrade
github.com/containerd/containerdtov1.7.33or later.v1.7.32is still affected by CRI logger path command-execution, DoS, and arbitrary log-file-read advisories; update the vendored modules as well.🧰 Tools
🪛 OSV Scanner (2.4.0)
[HIGH] 74-74: github.com/containerd/containerd 1.7.32: containerd image-triggered runtime DoS via unbounded group parsing
(GHSA-jpcc-p29g-p8mq)
[HIGH] 74-74: github.com/containerd/containerd 1.7.32: containerd CRI — image-config
LABELflows to restart-monitorbinary://logger: host-root command execution from an image pull(GHSA-xhf5-7wjv-pqxp)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@go.mod` at line 74, Upgrade the containerd dependency to remove the affected version: update the github.com/containerd/containerd entry in go.mod to v1.7.33 or newer, then refresh the vendored dependencies so the lockstep module set matches the new version. Make sure any references in the module graph that resolve through containerd are also updated consistently.Source: Linters/SAST tools
Add comprehensive evaluation tasks for the OVN-Kubernetes toolset covering four main tool categories: - ovn_get: List and query OVN database objects (routers, switches, chassis) with column selection and pattern filtering - ovn_lflow_list: List logical flows for specific datapaths with pattern matching - ovn_show: Display Northbound and Southbound database configurations - ovn_trace: Trace packets through OVN logical network with detailed, summary, and pattern-filtered output modes Update all three eval configurations (claude-code, gemini-agent, openai-agent) to include the new ovn-kubernetes task set. Signed-off-by: Arnab Ghosh <arnabghosh89@gmail.com>
61cd5d3 to
69aece9
Compare
|
@mattedallo: all tests passed! Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
Summary
Registers a new
ovn-kubernetestoolset as scaffolding for OVN-Kubernetes networking diagnostics integration (enhancements#2002).pkg/toolsets/ovnkubernetes/toolset.go— empty toolset implementingapi.Toolset, registered viainit()pkg/mcp/modules.goovn-kubernetesto theTestGranularToolsetsToolssnapshot test with an empty[]snapshotThe toolset ships with zero tools — sibling stories CORENET-7135 (OVS tools) and CORENET-7136 (OVN tools) will add tool handlers on top of this framework.
Verification
make build— binary compiles with the new toolsetmake test— all tests pass (including the new snapshot test)make lint— no lint violationsWhat is NOT in this PR
ovn-kubernetes-mcpGo dependency (arrives with tool implementations)Summary by CodeRabbit
Release Notes
New Features
ovn_show,ovn_get,ovn_lflow_list, andovn_trace, including Kubernetes-backed execution.Tests
Evaluation
ovn_get,ovn_lflow_list,ovn_show, andovn_tracescenarios.