[
https://issues.apache.org/jira/browse/YUNIKORN-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17891675#comment-17891675
]
Olivier Sevin commented on YUNIKORN-2895:
-----------------------------------------
Thanks Wilfred, I will follow that kubernetes issue.
"We should be able to remove the pod at that point. That does not happen or we
do not handle the pod status correctly when that happens."
If this helps narrow things down one thing I've noticed I can consistently make
this happen in 1.6.0 with or without the patch, but I haven't been able to
reproduce it in 1.5.2. Maybe this contradictory info about what node the pod is
on might make it harder to clean up
{
"nodeID": "gke-cr-west1-nap-n1-standard-2-6eig89-55fcd2da-xtqc",
"allocations": [ ...
{ ...
"allocationKey": "87f9d2dd-4933-449e-8159-e3a7bfb07501",
"allocationTags": { ...
"kubernetes.io/meta/podName": "dataops0000000002wcv-n0-0-driver"
},
"nodeId": "gke-cr-west1-nap-n1-standard-2-6eig89-55fcd2da-k9b8",
}
],
}
> Don't add duplicated allocation to node when the allocation ask fails
> ---------------------------------------------------------------------
>
> Key: YUNIKORN-2895
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2895
> Project: Apache YuniKorn
> Issue Type: Bug
> Components: core - scheduler
> Reporter: Qi Zhu
> Assignee: Qi Zhu
> Priority: Critical
> Labels: pull-request-available
> Attachments: orphaned_dataops_1.6_patched.json
>
>
> When i try to revisit the new update allocation logic, the potential
> duplicated allocation to node will happen if the allocation already
> allocated. And we try to add the allocation to the node again and don't
> revert it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
