[
https://issues.apache.org/jira/browse/YUNIKORN-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112773#comment-18112773
]
Dian-Xuan Yang commented on YUNIKORN-3437:
------------------------------------------
Hello , I took a closer look at this and did a quick audit against master at
edef7f7.
I found eight non-test call sites for K8s mutating operations:
||#||Op||Site||Cancellable||
|1|Bind|task.go:406|No|
|2|Delete|application.go:694 ā task.go:195|No|
|3|UpdateStatus|application.go:650 ā task.go:199|No|
|4|UpdatePod|task.go:203|N/A ā no callers|
|5|Create|placeholder_manager.go:90|No|
|6|Delete|placeholder_manager.go:112|Indirect|
|7|Delete|placeholder_manager.go:132|Partial|
|8|UpdateStatus|context.go:1235|No, although stopCtx is in scope|
A few things stood out:
* Site 1 (Bind) is the largest gap: it runs in an untracked goroutine and
retries unconditionally, with a backoff of up to 121 seconds.
* Site 8 looks like the simplest fix, since `stopCtx` is already available in
the calling goroutine.
* Site 4 appears to be dead code and has no callers.
* Site 2 is already covered by YUNIKORN-3382, and site 7 by YUNIKORN-3404.
Iād be happy to take site 1 (the bind path) first, as it appears to be the
largest gap.
Please let me know if this approach looks reasonable and whether we should
follow the context-bound pattern from YUNIKORN-3369.
The findings above are based on static code inspection; I have not yet verified
the actual shutdown timing with a runtime test.
> Handle shutdown signal during K8s CRUD operations
> -------------------------------------------------
>
> Key: YUNIKORN-3437
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3437
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: shim - kubernetes
> Reporter: Manikandan R
> Priority: Major
>
> [https://github.com/apache/yunikorn-k8shim/pull/1081/changes#diff-acd133004bc2ea568858d4a2fef2946e4c0e680a8189507583a4d39905c53e7e]
> &
> [https://github.com/apache/yunikorn-k8shim/pull/1078/changes#diff-93ac0a257135e0c327caf1b0addc39d063263975ec7f9c6ccb2e73f97a6bb662]
> are the one off places where shutdown signal is being handled properly to
> avoid blocking the API server. As a follow up, need to assess the other
> different places where K8s crud operations are being executed asynchronously
> and carry out the next steps accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
