You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> Improve HAMi-core startup performance when hundreds of processes initialize CUDA concurrently and compete for the shared unified lock. The work should follow the maintainer discussion in the upstream issue and preserve correctness while reducing initialization latency and contention.
182
+
>
183
+
> ## Expected outcomes
184
+
>
185
+
> - A reproducible benchmark for concurrent HAMi-core initialization.
186
+
> - A maintainer-approved locking design based on the approaches accepted in the upstream discussion.
187
+
> - An implementation with concurrency and regression tests.
188
+
> - Before-and-after measurements of startup latency, throughput, and relevant resource usage.
189
+
> - Documentation of the design, compatibility considerations, and operational impact.
190
+
> - The implementation submitted for HAMi maintainer review.
#### Fix GPU Memory Isolation for Child and SSH Processes
201
+
202
+
CNCF - HAMi: Fix GPU Memory Isolation for Child and SSH Processes (2026 Term 3)
203
+
204
+
- Description:
205
+
206
+
> ## Description
207
+
>
208
+
> Investigate and fix cases where processes started later inside a HAMi-managed container, including child processes and processes reached through SSH or a new login shell, may not retain the expected GPU memory limit. The first milestone is to reproduce the behavior on a current supported HAMi release. The implementation approach must be agreed with HAMi maintainers rather than assuming a specific configuration mechanism in advance.
209
+
>
210
+
> ## Expected outcomes
211
+
>
212
+
> - A reproducible test case and documented root cause.
213
+
> - A maintainer-reviewed design covering the intended isolation boundary, compatibility, and failure modes.
214
+
> - A maintainer-approved implementation, or a validated design and prototype if platform constraints prevent full delivery within the term.
215
+
> - Regression tests covering the original process, child processes, and supported SSH or new-shell scenarios.
216
+
> - Documentation of supported configuration, migration guidance, and known limitations.
217
+
> - The implementation submitted for HAMi maintainer review.
> Kyverno's maintainers spend significant recurring effort on low-judgment, repetitive tasks: reviewing/merging Dependabot PRs, keeping open PRs rebased with main and re-running CI, triaging a high volume of incoming issues, reproducing bug reports, running the right subset of conformance/unit tests for a given diff, and answering repeat questions in Slack/GitHub Discussions. This work competes for maintainer time with code review, design, and roadmap work, and slows down contributor turnaround (stale PRs, delayed triage labels, slow first response on issues).
326
+
>
327
+
> ## Expected Outcomes
328
+
>
329
+
> Build an AI Maintainer Assistant: a sandboxed, permission-scoped autonomous agent (e.g., running an agent runtime such as OpenHands/OpenClaw/Hermes-style sandboxed coding agent) that runs on a schedule and via GitHub/Slack webhooks to automate routine maintainer workflows, always via auditable, revertible actions (comments, labels, draft PRs).
330
+
331
+
- Recommended Skills: AI Engineering, AI agent harness, Claude Code, GitHub Copilot, GitHub Actions, Hermes
332
+
- Technologies: AI Engineering, AI agent harness, Claude Code, GitHub Copilot, GitHub Actions, Hermes
> Kyverno's CEL engine runs a whole pipeline on the way to an admit or deny (scope filtering, match conditions, variables, validation expressions, autogen rule expansion, mutation, exception handling) and discards the per-expression detail the moment it has a final answer. When a CEL policy does something surprising (matches a resource you didn't expect, skips one you did, denies with a message that doesn't say which clause fired, or fails with a bare "no such key"), there is no supported way to see which sub-expression produced which value.
348
+
>
349
+
> ## Expected Outcomes
350
+
>
351
+
> This feature proposes an opt-in, structured decision trace: capture what the engine already computes, once, in a stable machine-readable form, and surface it where users look (the CLI first, then reports and the running controller). It broadens KDP https://github.com/kyverno/kyverno/pull/91 from a two-phase CLI-plus-runtime feature into a decision-explainability primitive for the whole CEL pipeline.
352
+
353
+
- Recommended Skills: Kubernetes, Golang, CEL
354
+
- Technologies: Kubernetes, Golang, CEL
355
+
- Mentor(s):
356
+
- Jim Bugwadia (@JimBugwadia, jim@nirmata.com)
357
+
- Jyotiraditya Panda (@rx18-eng, remopanda7@gmail.com)
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4&size=40){kind=avatar}
0 commit comments