wilfred-s commented on PR #628: URL: https://github.com/apache/yunikorn-k8shim/pull/628#issuecomment-1623043203
> reusing app ids can happen either accidentally or even automatically (especially for the autogenerated app id) This does not affect re-using application IDs. You can still do that without a problem. If the application is not currently known in the shim the user info will be set without question. For the auto generated app ID: I do think that is a case we need to handle and not reject. > Tracking users by app instead of pod leads to this (IMO small) issue, but I don't think we should disallow behavior that Kubernetes allows -- we should strive to be more compatible, not less. K8s does not have the concept of applications and or users on a workload so we have no compatibility look at. Looking at a simple case: I could set a Spark application ID on a pod as a completely different user, in a different namespace with a different service account etc. That pod will then be run as part of the already running Spark job in a queue which I might not have access to under a different quota. That is a huge gap which will show up as a problem. I am surprised that it has not as yet. > I don't see this issue being much worse than the ambiguity we have in the case of group quotas and multiple possible matches. It's not perfect, but probably good enough. The group resolution is defined and far less of a problem than this is. The reason for adding this is that we have seen abuse similar to this on YARN years ago. We have to put mitigations in place. Even if they are off by default but we need to have them. -- 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]
