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
Refactoring + Cleanup to scheduler +utils for modularizing checkServiceAffinity. #34624
Refactoring + Cleanup to scheduler +utils for modularizing checkServiceAffinity. #34624
Conversation
e250694
to
afd8864
Compare
1ce8291
to
f0164a8
Compare
Just rebased |
Jenkins GCI GKE smoke e2e failed for commit f0164a8. Full PR test history. The magic incantation to run this job again is |
import "k8s.io/kubernetes/pkg/api" | ||
|
||
// findLabelsInSet gets as many constraints as possible from the pod itself. | ||
func findLabelsInSet(labelsToKeep []string, nodeSelector labels.Set) 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.
Is there a reason why these are private, as they seem generally useful?
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 felt like this was made as a utility for making the nodeSelection stuff more understandable, and the semantics weren't defined well (i.e. findLabelsInSet vs filterLabelsFromMap vs ...) and it wasnt thought-out enough to generalize. In any case, happy to make it public.... what are your thoughts ? im +0 to public but can do if you still feel like we should.
// The pod is checked for the labels and any missing labels are then checked in the node | ||
// that hosts the service pods (peers) for the given pod. | ||
// The checkServiceAffinity predicate matches nodes in such a way to force that | ||
// ServiceAffinity.labels are homogenous for pods added to a node. | ||
// |
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: remove this line
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.
The line is to separate the concise definition from the drivel :):). But yeah I can delete.
|
||
// ExampleUtils is a https://blog.golang.org/examples styled unit test. | ||
func ExamplefindLabelsInSet() { | ||
|
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: remove this empty line
@@ -39,7 +39,8 @@ type PriorityMapFunction func(pod *api.Pod, meta interface{}, nodeInfo *schedule | |||
type PriorityReduceFunction func(pod *api.Pod, result schedulerapi.HostPriorityList) error | |||
|
|||
// MetdataProducer is a function that computes metadata for a given pod. | |||
type MetadataProducer func(pod *api.Pod) interface{} | |||
// In some cases NodeInfo is required in order for certain types of metadata caching, but leaving nil may be ok in many cases also. |
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 would remove this comment, because it basically says "nodeNameToInfo may be required, but may also not be required" (which basically doesn't say anything)
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.
True, but remember the odd thing is that this interface is used for different factorIes. I guess I can directly say that in the comment rather
// will_see_this | ||
// label1=value1,label2=value2,label3=will_see_this | ||
// [&TypeMeta{Kind:,APIVersion:,} &TypeMeta{Kind:,APIVersion:,}] | ||
|
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: remove this empty line
addUnsetLabelsToMap(labelSubset, []string{"label1", "label2", "label3"}, nsPods[0].ObjectMeta.Labels) | ||
|
||
fmt.Println(labelSubset) | ||
|
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: remove this empty line
return filtered | ||
} | ||
|
||
// createSelectorFromLabels is used to define the final selector which we will use to decide wether a pod |
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 wouldn't mention pod or node here - it is pretty generic function.
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.
hmmm i think the semantics are really only useful to predicates and pods (even though its generalizable, it probably will never be used outside this package)... but i guess...
|
||
{}, // a third pod which will have no effect on anything. | ||
} | ||
|
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: remove this empty line
fmt.Println(findLabelsInSet([]string{"label1", "label2", "label3"}, nsPods[0].ObjectMeta.Labels)["label3"]) | ||
|
||
addUnsetLabelsToMap(labelSubset, []string{"label1", "label2", "label3"}, nsPods[0].ObjectMeta.Labels) | ||
|
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: remove this empty line
// Output: | ||
// will_see_this | ||
// label1=value1,label2=value2,label3=will_see_this | ||
// [&TypeMeta{Kind:,APIVersion:,} &TypeMeta{Kind:,APIVersion:,}] |
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.
This doesn't give any information (we don't know which pods were filtered out). So maybe just print the number of pods that are in this namespace?
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 considered that, but this is simpler to maintain if we expand the pod meta data for the test ...
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.
So let's print those pods so that we know what pods they are. This doesn't provide much value now.
// the match. | ||
// Otherwise: | ||
// Create an "implicit selector" which backfills node label selectors for a pod, such that it will land with | ||
// matching labelled nodes to pre-existing pods. |
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's probably due to my english, but I'm lost in this sentence. Can you please clarify?
f0164a8
to
dce8911
Compare
Jenkins verification failed for commit dce89117a0f296012168ca82a53c315973f0c184. Full PR test history. The magic incantation to run this job again is |
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.
One minor outstanding comment. other than that lgtm
Also please fix "Jenkins verification" |
…ation for predicate injection support, Update metadata struct
dce8911
to
182e89b
Compare
Namespace: "ns1", | ||
}, | ||
}, | ||
|
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.
blank line here intentional : to separate the third pod from the other two for readability
i believe all comments addressed now... |
i think jenkins verify looks ok to me ? |
lgtm |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue |
Part 1 of pr for scheduler modularization specifically supporting CheckServiceAffinity improvements #33763.
These are some innoccous changes which help separate the predicate injection machinery from the cleanup parts of CheckServiceAffinity
@timothysc @wojtek-t
hoping to grease this through and then the interesting part is in the follow on pr.
This change is