-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[YUNIKORN-2230] Placement rule does not behave as expected #748
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #748 +/- ##
==========================================
- Coverage 69.46% 69.45% -0.01%
==========================================
Files 50 50
Lines 7993 7992 -1
==========================================
- Hits 5552 5551 -1
Misses 2252 2252
Partials 189 189 ☔ View full report in Codecov by Sentry. |
This is more a design and behavioural question than a code review. |
Thank's for the comment! Indeed, that is a better way and doing so won't break anything. I'll make the setting |
I also have another minor question: should we consider renaming these two settings (admissionController.filtering.defaultQueueName and admissionController.filtering.generateUniqueAppId)? Since they not only control the admission controller but also influence K8Shim, perhaps a more descriptive name would be appropriate. |
gentle ping @wilfred-s However, if I set DefaultQueueName as non-reloadable, changing the default queue name to |
pardon me, is this a potential issue? Are there any reasons that users have to change the default queue name by re-reconfiguring? |
The admission controller handles it as a reloadable value. We can do either. However I think that the value should be reloadable as we can change the queue config and placement rules on the fly also. If you do not allow it to be reloadable a queue config change could be applied by the default queue would not change causing rejects etc. Keeping them both reloadable would be better. |
queueName = qu | ||
if queueName := GetPodLabelValue(pod, constants.LabelQueueName); queueName != "" { | ||
return queueName | ||
} else if queueName := GetPodAnnotationValue(pod, constants.AnnotationQueueName); queueName != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: No need to have an else
here as we return if we have a queue above
What is this PR for?
Fix issue with the placement rules, specifically the one where the provided rule (when
created
is true) is applied before the tag rule, is not functioning as intended. The root cause lies in the GetQueueNameFromPod function in the shim, which automatically adds a default queue name to a pod if none is specified. As a result, the provided rule (whencreated
is true) is consistently applied, preventing the tag rule from being triggered.What type of PR is it?
Todos
N/A
What is the Jira issue?
https://issues.apache.org/jira/browse/YUNIKORN-2230
How should this be tested?
covered by e2e test
Screenshots (if appropriate)
N/A
Questions: