-
Notifications
You must be signed in to change notification settings - Fork 141
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-1351] alway prefer annotations above labels #677
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #677 +/- ##
==========================================
+ Coverage 71.32% 71.46% +0.14%
==========================================
Files 43 43
Lines 7592 7679 +87
==========================================
+ Hits 5415 5488 +73
- Misses 1976 1988 +12
- Partials 201 203 +2 ☔ View full report in Codecov by Sentry. |
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.
Need some minor changes. Thanks for the contribution.
We need to be very, very careful about this implementation. To support backwards compatibility, we need to honor labels for the foreseeable future. In the admission controller, we should do the following:
In the shim, we need to then check for the annotation first, and then fall back to the label (or in the case of applicationID, use Spark ApplicationID if neither is present). We can't simply look at the annotations alone, as users may not use the admission controller at all, and there may also be existing long-running pods that only contain labels. |
Thanks @FrankYang0529 , @craigcondit 's comment. I'll update a new version which will keep the original labels for backforward, and create missing annotations from corresponding labels. |
Hi @FrankYang0529, @craigcondit, @wilfred-s I just uploaded a newer version of commit, could I have your review? The existing labels are still kept in admission controller and will be added to annotation if the corresponding tag are not existing in pod. Below is the newer change list of the whole PR:
Since this PR modified the core part of admission controller, I might need your help to review, expecially for # 5 and # 6. |
Hi @FrankYang0529 , after dived into the error in CI (v1.24.15) Could you help to re-trigger CI? I don't think it will happen every time |
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.
First round from me.
for k, v := range existingLabels { | ||
result[k] = v | ||
} | ||
func getNewApplicationInfo(pod *v1.Pod, namespace string, generateUniqueAppIds bool, defaultQueueName string) (map[string]string, map[string]string) { |
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.
In this function, I think it's useful to issue a warning to the user that labels will be deprecated in a later release, so they must adapt their app submission logic to this. It's very easy to forget about this and we must reduce the surprise factor.
What I'd do: return an extra bool from getApplicationIDFromPod()
, getDisableStateAwareFromPod()
, utils.GetQueueNameFromPod()
to indicate whether a source was a label. If there's at least one of them is true, log something useful:
if appIdLabel || stateAwareFromLabel || queueNameFromLabel {
log.Log(log.Admission).Warn("Pod contains label for Yunikorn configuration. This is deprecated and will be
ignored in a future release. Please migrate to annotation-based configuration.",
zap.Bool("appId from label", appIdLabel),
zap.Bool("stateAware from label", stateAwareFromLabel),
zap.Bool("queue name from label", queueNameFromLabel))
}
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.
Add deprecated warning if applicationInfo is from labels (cf71eef)
- Return extra bool 'isFromLabel' as suggested
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.
I don't think we can even deprecate the labels (especially applicationId
) -- they are far too entrenched in the existing ecosystem (and arguably applicationId
should be a label anyway to allow querying pods by applicationId). I think our best best is simply to use the annotation if it exists, and fallback to the label if it does not.
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.
It make sense to me, let's discuss the expecting AM behavior in below discussion.
5da2d22
to
f48e089
Compare
Thanks @pbacsko's review, I've updated a newer version based on the feedbacks. |
7beb9aa
to
4305c07
Compare
Hi @pbacsko, sorry for late update. I just rebase the commits and solve some conflicts. |
@chenyulin0719 thanks, I'll take a look shortly. |
queueName, isQueueNameFromLabel := utils.GetQueueNameFromPod(pod, defaultQueueName) | ||
|
||
if isAppIdFromLabel || isDisableStateAwareFromLabel || isQueueNameFromLabel { | ||
log.Log(log.Admission).Warn("Pod contains label for Yunikorn configuration. This is deprecated and will be ignored in a future release. Please migrate to annotation-based configuration.", |
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.
I've already talked to @craigcondit about this, we might not be in a position to ever remove this, it's going to be too dangerous. Also, certain settings actually should be specified as labels because that allows pods to be grouped/selected based on certain criteria. Let's think about it.
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.
I agree with the benefits of using label in terms of grouping and selecting.
Deprecate it might result in users unable to implement alternative solution.
Regarding this PR:
- always prefer annotation above label.
- Move labels to annotation, but keep existing labels before deprecation.
Before making any change, I think we need to align the scope again.
Below are my questions if we are not going to deprecate the labels:
- Will AM patch missing attributes to label only? Or patch to label and annotation both?
-> I think for 'applicationID' and 'queue', we should patch to both. - How about the existing label "disableStateAware"?
-> I think we can just change it to annotation because it's only be set in AM.
-> This label could be deprecated. (Or suggest not using it) - If we have a different applicationID set in label/annotation, do we still prefer annotation above label.
-> I think the answer is yes for consistency, we must guide user not to set different value if they require labels for selecting/grouping. - If only annotations were set in pod, should AM patch it(app-id, queue) to label?
-> Yes, align with my answer of question 1 - If only labels were set in pod, should AM patch it(applicationId, queue) to annoataion?
-> Yes, align with my answer of question 1
My summary of new version:
- Always prefer annotation above labels
- AM ensure applicationID/queue existing in label and annotation.
- Change label "disableStateAware" to annotation.
@pegasas, do you have any feedback?
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.
Also needs @wilfred-s 's review too.
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.
Sorry, I just pinged the wrong person.
@pbacsko,@craigcondit , do you have any feedback for the new version of AM behaviror?
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.
@pbacsko, @craigcondit ,
After reconsideration, if deprecated labels are no longer needed, I can revert most of the AM changes to keep this PR simple. We can maintain the previous UpdateLabel behavior for AM. Just make sure to always get annotation before labels when accessing the value.
Will update a version with this idea, please let me know if you have any concern.
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.
I'd like to get @wilfred-s to weigh in on this one.
Close it as new policy for labels and annotations is defined in YUNIKORN-1351. |
What is this PR for?
Since we're looking for deprecated labels and move everything to annotation in the future.
This PR change newly added labels to annotations in admission controller when mutating the pods.
This PR also fix existing mismatch to align the logic of "fetching annotations from Pods takes precedence over labels."
Below are the detailed change list:
What type of PR is it?
Todos
What is the Jira issue?
https://issues.apache.org/jira/browse/YUNIKORN-1351
How should this be tested?
Screenshots (if appropriate)
Before vs After result. (Pod with existing applicationId, queue labels.)
Before vs After result. (Pod with no label.)
Questions: