You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@yunikorn.apache.org by GitBox <gi...@apache.org> on 2022/03/01 06:57:32 UTC

[GitHub] [incubator-yunikorn-k8shim] anuraagnalluri edited a comment on pull request #369: [YUNIKORN-1040] add e2e test that re-starts the scheduler pod

anuraagnalluri edited a comment on pull request #369:
URL: https://github.com/apache/incubator-yunikorn-k8shim/pull/369#issuecomment-1055074537


   @ronazhan That was one suspicion I had which is why I port-forwarded the service instead of the pod. The pod has a unique UUID post restart, but the service remains static. Since the command would effectively be for the same service, would we have to kill the old process and start a new one? It's difficult to verify what may be causing `fallback_test` to fail locally, because even when rebuilding the images on `master` and running the test, it reliably fails/times out [here](https://github.com/apache/incubator-yunikorn-k8shim/blob/master/test/e2e/state_aware_app_scheduling/fallback_test.go#L80). This happens regardless of whether `port-forward` proc is running or not on `master` and my task branch.
   
   @yangwwei Makes sense, I think it would be good for removing gosec exclusion. I think the actual code the blog refers to [does block the main process](https://github.com/gianarb/kube-port-forward/blob/master/main.go#L111) until [`stopCh` is closed ](https://github.com/gianarb/kube-port-forward/blob/master/main.go#L79-L80). But we can likely remove the syncs from our implementation to make it non-blocking, right? 


-- 
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: reviews-unsubscribe@yunikorn.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org