tigerquoll commented on PR #1061:
URL: https://github.com/apache/yunikorn-k8shim/pull/1061#issuecomment-5565654178
Rebased onto master (`fa7b6add`) and pushed. One thing changed since the
last round, and one thing about master needs flagging.
**The shim-side burn-down is now complete.** YUNIKORN-3369 (#1078) landed on
1 Sep and aborts the AssumePod retry loop on shutdown, which retires the last
exemption whose cause was in shim code. This PR opened with four shim-owned
carve-outs; 3367 removed three and 3369 removes the last. `shimOwnedOptions()`
is now empty, so a new shim-owned leak fails the build instead of getting an
entry.
@wilfred-s — this answers your point directly: *"There should not be any
exception from our code that could be fixed."* There now isn't one. All 17
remaining `pkg/shim` entries come from yunikorn-core service goroutines the
shim starts in-process and cannot stop in tests, and they burn down with
YUNIKORN-3370.
@manirajv06 — the JIRA-referencing rework you asked for is in and has now
had two cycles of evidence behind it: the exemptions the comments pointed at
are the ones that actually got fixed.
**Master does not currently compile,** which is why CI here is red. The
YUNIKORN-3435 SI bump (`a2222d65`) added `PreFilterPredicates` to
`api.ResourceManagerCallback` before #1043 implements it in the shim:
```
pkg/cache/scheduler_callback.go:44:37: cannot use &AsyncRMCallback{} ...
does not implement
api.ResourceManagerCallback (missing method PreFilterPredicates)
```
That reproduces on a clean checkout of master, and master's own CI has
failed on it since 4 Sep — run
[33974617433](https://github.com/apache/yunikorn-k8shim/actions/runs/33974617433).
Nothing in this PR touches production code, so this PR cannot be the cause. I
verified the change locally with a throwaway stub of that one method (not
committed, not in the diff): all 18 instrumented packages green under `-race
-tags deadlock`, plus `golangci-lint`, `go vet`, `gofmt`, `make license-check`
and `go mod tidy` clean.
While re-verifying I also re-probed every exemption against the current core
pin by deleting it and checking the result. Two things worth recording: no core
frame was renamed by this dependency bump (unlike the previous one), and the
YUNIKORN-3365 entry is the only one that no longer reproduces — five
consecutive runs without it were green. I have kept it, and said so in the
comment, because 3365 is still open and the wedge is a shutdown race; a leak
that surfaces once in CI costs more than an entry that costs nothing. Happy to
drop it if you would rather the list carry only entries that fire on demand.
Generated by the Author with assistance from Claude Code
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
