Fix filter plugins are not been called during preemption #81876

wgliang · 2019-08-24T00:39:36Z

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind bug

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #81866

Special notes for your reviewer:
@alculquicondor

Does this PR introduce a user-facing change?:

Fix filter plugins are not been called during preemption

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

NONE

wgliang · 2019-08-24T00:41:12Z

/sig scheduling
/priority important-soon

draveness

cc/ @alculquicondor

draveness · 2019-08-24T04:06:10Z

pkg/scheduler/core/generic_scheduler.go

@@ -1121,7 +1136,7 @@ func selectVictimsOnNode(
 	// inter-pod affinity to one or more victims, but we have decided not to
 	// support this case for performance reasons. Having affinity to lower
 	// priority pods is not a recommended configuration anyway.
-	if fits, _, err := podFitsOnNode(pod, meta, nodeInfoCopy, fitPredicates, queue, false); !fits {
+	if fits, _, err, _ := podFitsOnNode(pluginContext, pod, meta, nodeInfoCopy, fitPredicates, queue, false, filterPluginsFunc); !fits {


I think the following is correct since the err is the last return value

Suggested change

if fits, _, err, _ := podFitsOnNode(pluginContext, pod, meta, nodeInfoCopy, fitPredicates, queue, false, filterPluginsFunc); !fits {

if fits, _, _, err := podFitsOnNode(pluginContext, pod, meta, nodeInfoCopy, fitPredicates, queue, false, filterPluginsFunc); !fits {

draveness · 2019-08-24T04:07:30Z

pkg/scheduler/core/generic_scheduler.go

 	pod *v1.Pod,
 	meta predicates.PredicateMetadata,
 	info *schedulernodeinfo.NodeInfo,
 	predicateFuncs map[string]predicates.FitPredicate,
 	queue internalqueue.SchedulingQueue,
 	alwaysCheckAllPredicates bool,
-) (bool, []predicates.PredicateFailureReason, error) {
+	filterPluginsFunc func(pc *framework.PluginContext, pod *v1.Pod, nodeName string) *framework.Status,


why are you using the function as a parameter? what about the framework

Thanks @draveness
IMO, from now on, it is sufficient to pass filterPluginsFunc, which seems to be better from the perspective of minimum function implementation and testing.

On the other hand, this approach has the following drawbacks:

Harder to read, IDEs can't find all the references to Framewokr.RunFilterPlugins

We have repeated code for the function prototype. Refactoring takes longer.

If we have a proper fake Framework, testing shouldn't be a problem. Also, we should prefer to test exported interfaces.

If we have a proper fake Framework, testing shouldn't be a problem. Also, we should prefer to test exported interfaces.

We do have a fakeFramework in scheduling_queue_test.go

I don't see a value in passing the function as a parameter, it is not easy to follow. Make podFitsOnNode, selectVictimsOnNode and selectNodesForPreemption private methods of genericScheduler, and that will give you access to the framework.

@ahg-g Agree with you, one more parameter is really unnecessary, whether it is framework or filterPluginsFunc.

draveness · 2019-08-24T04:09:05Z

pkg/scheduler/core/generic_scheduler.go

 	nodeNameToInfo map[string]*schedulernodeinfo.NodeInfo,
 	potentialNodes []*v1.Node,
 	fitPredicates map[string]predicates.FitPredicate,
 	metadataProducer predicates.PredicateMetadataProducer,
 	queue internalqueue.SchedulingQueue,
 	pdbs []*policy.PodDisruptionBudget,
+	filterPluginsFunc func(pc *framework.PluginContext, pod *v1.Pod, nodeName string) *framework.Status,


draveness · 2019-08-24T04:13:33Z

pkg/scheduler/core/generic_scheduler.go

@@ -525,7 +515,15 @@ func (g *genericScheduler) findNodesThatFit(pluginContext *framework.PluginConte
 				}
 			} else {
 				predicateResultLock.Lock()
-				failedPredicateMap[nodeName] = failedPredicates
+				if status != nil && !status.IsSuccess() {


nit: !status.IsSuccess() won't panic even if the status is nil, please take a look at the implementation of IsSuccess function.

Sorry, I understand that you don't mean it. You mean that when the status is nil, calling status.IsSusccess() won't panic?
nil is untyped, my understanding will get an error similar to use of untyped nil panic error.

If my understanding is wrong, please let me know. Thanks. :)

Sorry, I understand that you don't mean it. You mean that when the status is nil, calling status.IsSusccess() won't panic?

Please take a look at https://github.com/kubernetes/kubernetes/pull/81876/files#diff-c237cdd9e4cb201118ca380732d7f361L509

It is a typed nil, I created a snippet here which shows it won't cause panic.

package main import ( "fmt" ) type Status struct{} func (s *Status) IsSuccess() bool { if s == nil { return true } return false } func main() { st := returnStatus() fmt.Println(st.IsSuccess()) } func returnStatus() *Status { return nil } package main import ( "fmt" ) type Status struct{} func (s *Status) IsSuccess() bool { if s == nil { return true } return false } func main() { st := returnStatus() fmt.Println(st.IsSuccess()) } func returnStatus() *Status { return nil } $ go run ... true

cool! I got it.

hex108 · 2019-08-24T13:34:09Z

As mentioned in comment, how about converting podFitsOnNode to default filter plugin, then genericScheduler.Preempt calls framework.RunFilterPlugins instead of podFitsOnNode?

draveness · 2019-08-24T16:39:18Z

As mentioned in comment, how about converting podFitsOnNode to default filter plugin, then genericScheduler.Preempt calls framework.RunFilterPlugins instead of podFitsOnNode?

There could be a lot of compatible work to do since they are using two different error systems, I have tried once but cause a lot of trouble which looks quite like a hack, and this PR is a fine approach to solve this issue IMO.

draveness · 2019-08-24T16:42:23Z

cc/ @alculquicondor

alculquicondor · 2019-08-26T12:26:38Z

pkg/scheduler/core/generic_scheduler.go

@@ -137,7 +137,7 @@ type ScheduleAlgorithm interface {
 	// the pod by preempting lower priority pods if possible.
 	// It returns the node where preemption happened, a list of preempted pods, a
 	// list of pods whose nominated node name should be removed, and error if any.
-	Preempt(*v1.Pod, error) (selectedNode *v1.Node, preemptedPods []*v1.Pod, cleanupNominatedPods []*v1.Pod, err error)
+	Preempt(*framework.PluginContext, *v1.Pod, error) (selectedNode *v1.Node, preemptedPods []*v1.Pod, cleanupNominatedPods []*v1.Pod, err error)


pod and then pluginContext? I prefer we are consistent with Schedule

I prefer the keep the context as the first argument, there is a chance it would conform context.Context.

@alculquicondor
FYI:https://golang.org/pkg/context/
The Context should be the first parameter

This is not currently an implementation of context.Context, so it doesn't apply. That said, we should consider rearranging the parameters in Schedule along with Preempt. But that shouldn't be in this PR.

+1 to Aldo's suggestion regarding rearranging the Schedule to be consistent with Preempt in a separate PR.

Ok. I will do that. :)

IMO we could accept this since we have already reached a consensus on conforming the Context in #81433 and #82072 is making the change.

alculquicondor · 2019-08-26T12:32:18Z

pkg/scheduler/core/generic_scheduler.go

 	pod *v1.Pod,
 	meta predicates.PredicateMetadata,
 	info *schedulernodeinfo.NodeInfo,
 	predicateFuncs map[string]predicates.FitPredicate,
 	queue internalqueue.SchedulingQueue,
 	alwaysCheckAllPredicates bool,
-) (bool, []predicates.PredicateFailureReason, error) {
+	filterPluginsFunc func(pc *framework.PluginContext, pod *v1.Pod, nodeName string) *framework.Status,


On the other hand, this approach has the following drawbacks:

Harder to read, IDEs can't find all the references to Framewokr.RunFilterPlugins

We have repeated code for the function prototype. Refactoring takes longer.

If we have a proper fake Framework, testing shouldn't be a problem. Also, we should prefer to test exported interfaces.

alculquicondor · 2019-08-26T12:34:23Z

pkg/scheduler/core/generic_scheduler.go

+
+	// Iterate each plugin to verify current node
+	status := filterPluginsFunc(pluginContext, pod, info.Node().Name)
+	if !status.IsSuccess() {


This doesn't seem necessary. We can directly return, right?

It would be more clear to seperate the good and base cases IMO

the return value is the same, I don't see the point.

I don't see the need for the returned boolean, whether or not the pod fits on the node is easily determined by the other returned values, so I suggest we just return failedPredicates, status, nil here.

Thanks @ahg-g review. IMO, we need to return a bool type value to indicate whether the current node matches.

Because the results cannot be directly determined based on failedPredicates or err, this is because L663 and L681. Indeed, we can check both len(failedPredicates) and err, but this undoubtedly brings complexity to the judgment. We need more readable and easy to understand processing logic.

alculquicondor · 2019-08-26T12:40:30Z

pkg/scheduler/core/generic_scheduler.go

@@ -1121,7 +1136,7 @@ func selectVictimsOnNode(
 	// inter-pod affinity to one or more victims, but we have decided not to
 	// support this case for performance reasons. Having affinity to lower
 	// priority pods is not a recommended configuration anyway.
-	if fits, _, err := podFitsOnNode(pod, meta, nodeInfoCopy, fitPredicates, queue, false); !fits {
+	if fits, _, _, err := podFitsOnNode(pluginContext, pod, meta, nodeInfoCopy, fitPredicates, queue, false, filterPluginsFunc); !fits {
 		if err != nil {


what about status? That could be an error as well.

alculquicondor · 2019-08-26T12:45:24Z

pkg/scheduler/core/generic_scheduler_test.go

@@ -1330,7 +1330,8 @@ func TestSelectNodesForPreemption(t *testing.T) {
 			newnode := makeNode("newnode", 1000*5, priorityutil.DefaultMemoryRequest*5)
 			newnode.ObjectMeta.Labels = map[string]string{"hostname": "newnode"}
 			nodes = append(nodes, newnode)
-			nodeToPods, err := selectNodesForPreemption(test.pod, nodeNameToInfo, nodes, test.predicates, PredicateMetadata, nil, nil)
+			pluginContext := framework.NewPluginContext()
+			nodeToPods, err := selectNodesForPreemption(pluginContext, test.pod, nodeNameToInfo, nodes, test.predicates, PredicateMetadata, nil, nil, func(pc *framework.PluginContext, pod *v1.Pod, nodeName string) *framework.Status { return nil })


Can we add a test for what we are adding? preemption when the filter plugins keep filtering the nodes.

Did you work on this?

Sorry, I missed it. If I am not mistaken, the test case you are talking about is actually to confirm that the filter plugins are also executed when preemption occurs.

This does not seem to be a test case, but rather the number of times the filter plugins are executed.

I will check filterPlugin.numFilterCalled with the expected in TestSelectNodesForPreemption. What do you think of this?

that sounds good. But you could also check that a plugin responds Unschedulable in the preemption phase and then the node is not returned in the list.

alculquicondor · 2019-08-26T12:48:24Z

pkg/scheduler/scheduler.go

@@ -349,14 +349,14 @@ func (sched *Scheduler) schedule(pod *v1.Pod, pluginContext *framework.PluginCon
 // preempt tries to create room for a pod that has failed to schedule, by preempting lower priority pods if possible.
 // If it succeeds, it adds the name of the node where preemption has happened to the pod spec.
 // It returns the node name and an error if any.
-func (sched *Scheduler) preempt(fwk framework.Framework, preemptor *v1.Pod, scheduleErr error) (string, error) {
+func (sched *Scheduler) preempt(pluginContext *framework.PluginContext, fwk framework.Framework, preemptor *v1.Pod, scheduleErr error) (string, error) {


the framework should be available in sched.Framework. Pass pluginContext as second argument to for consistency with schedule

Like the reply above, I actually prefer to update pass pluginContext as first argument with schedule.

I don't disagree, but please do it in a separate PR.

FYI, this is being handled in #82072

We should do this in a separate small PR because we don't know if #82072 will move forward or not, and if yes in what form, so it may take a little while to merge.

ahg-g

Thanks for sending this PR, I took a quick look, I will take another look once the comments are addressed.

ahg-g · 2019-08-27T00:51:33Z

pkg/scheduler/core/generic_scheduler.go

-				failedPredicateMap[nodeName] = failedPredicates
+				if !status.IsSuccess() {
+					filteredNodesStatuses[nodeName] = status
+					if status.Code() != framework.Unschedulable {


podFitsOnNode should return an error if this happens, so we shouldn't check here again.

this is not addressed yet.

DONE,Thanks!

ahg-g · 2019-08-27T01:12:49Z

pkg/scheduler/core/generic_scheduler.go

 	pod *v1.Pod,
 	meta predicates.PredicateMetadata,
 	info *schedulernodeinfo.NodeInfo,
 	predicateFuncs map[string]predicates.FitPredicate,
 	queue internalqueue.SchedulingQueue,
 	alwaysCheckAllPredicates bool,
-) (bool, []predicates.PredicateFailureReason, error) {
+	filterPluginsFunc func(pc *framework.PluginContext, pod *v1.Pod, nodeName string) *framework.Status,


I don't see a value in passing the function as a parameter, it is not easy to follow. Make podFitsOnNode, selectVictimsOnNode and selectNodesForPreemption private methods of genericScheduler, and that will give you access to the framework.

ahg-g · 2019-08-27T14:02:36Z

pkg/scheduler/core/generic_scheduler.go

@@ -137,7 +137,7 @@ type ScheduleAlgorithm interface {
 	// the pod by preempting lower priority pods if possible.
 	// It returns the node where preemption happened, a list of preempted pods, a
 	// list of pods whose nominated node name should be removed, and error if any.
-	Preempt(*v1.Pod, error) (selectedNode *v1.Node, preemptedPods []*v1.Pod, cleanupNominatedPods []*v1.Pod, err error)
+	Preempt(*framework.PluginContext, *v1.Pod, error) (selectedNode *v1.Node, preemptedPods []*v1.Pod, cleanupNominatedPods []*v1.Pod, err error)


+1 to Aldo's suggestion regarding rearranging the Schedule to be consistent with Preempt in a separate PR.

ahg-g · 2019-08-27T14:38:27Z

pkg/scheduler/core/generic_scheduler.go

+	}
+
+	// Iterate each plugin to verify current node
+	status := filterPluginsFunc(pluginContext, pod, info.Node().Name)


we should run the filter plugins inside the for i := 0; i < 2; i++ { loop (at the end) so that they get examined with and without nominated pods.

Also, return error in case status is not one of the expected values (not Success or Unschedulable).

Another thing we need to think about is whether or not we should pass the alwaysCheckAllPredicates flag to RunFilterPlugins.

I suggest a separate PR to complete this.

We don't need a separate PR for the first comment, this is part of addressing the bug.

ahg-g · 2019-08-27T14:49:02Z

pkg/scheduler/core/generic_scheduler.go

+
+	// Iterate each plugin to verify current node
+	status := filterPluginsFunc(pluginContext, pod, info.Node().Name)
+	if !status.IsSuccess() {


I don't see the need for the returned boolean, whether or not the pod fits on the node is easily determined by the other returned values, so I suggest we just return failedPredicates, status, nil here.

alculquicondor · 2019-08-29T13:36:04Z

pkg/scheduler/core/generic_scheduler.go

+
+		// Iterate each plugin to verify current node
+		status = g.framework.RunFilterPlugins(pluginContext, pod, info.Node().Name)
+		if !status.IsSuccess() && status.Code() != framework.Unschedulable {


use status.IsUnschedulable or even, what about simply if status.Code() == framework.Error?

we should use !status.IsUnschedulable() not status.Code() == framework.Error because Success and Unschedulable* are the only two valid statues that we expect from filters, all other statuses should be considered errors.

alculquicondor · 2019-08-29T13:42:07Z

pkg/scheduler/core/generic_scheduler.go

 		if err != nil {
 			klog.Warningf("Encountered error while selecting victims on node %v: %v", nodeInfo.Node().Name, err)
 		}
+
+		if !status.IsSuccess() {


It looks like you already handle it in podFitsOnNode, when you return status.AsError()

There may be unschedulable here.

My understanding is that these warnings are for actual errors. Also, if the filters failed, this conditional and the one about would both produce the same output, which is bad for troubleshooting when looking at logs.

I agree, we shouldn't have this warning.

alculquicondor · 2019-08-29T13:43:05Z

pkg/scheduler/core/generic_scheduler_test.go

@@ -653,7 +653,7 @@ func TestGenericScheduler(t *testing.T) {
 				schedulerapi.DefaultPercentageOfNodesToScore,
 				false)
 			result, err := scheduler.Schedule(test.pod, framework.NewPluginContext())
-			if !reflect.DeepEqual(err, test.wErr) {
+			if err != nil && !reflect.DeepEqual(err, test.wErr) {


why is this change necessary?

Because the returned err may be nil, otherwise reflect.DeepEqual(err, test.wErr) in test will panic.

reflect.DeepEqual(err, test.wErr) in test will panic

No, it won't panic.
https://play.golang.org/p/nLXk5MDyc7k

In this line of code, I did get a null pointer error in my development environment, which is why I originally made this change. But I found that it doesn't exist now, so weird.

I have cancelled this change, thanks for all of you reminding me.

alculquicondor · 2019-08-29T13:45:26Z

pkg/scheduler/core/generic_scheduler_test.go

@@ -1307,6 +1307,9 @@ func TestSelectNodesForPreemption(t *testing.T) {
 	labelKeys := []string{"hostname", "zone", "region"}
 	for _, test := range tests {
 		t.Run(test.name, func(t *testing.T) {
+			g := &genericScheduler{
+				framework: emptyFramework,


Can we add some tests with a non-empty framework? Basically, to have a regression test.

TestSelectNodesForPreemption mainly tests selectNodesForPreemption, so the empty framework does not seem to be necessary. However, I have changed to a non-empty framework. If I understand your comment, please let me know, thanks. :)

ahg-g · 2019-08-29T14:23:59Z

pkg/scheduler/core/generic_scheduler.go

+
+		// Iterate each plugin to verify current node
+		status = g.framework.RunFilterPlugins(pluginContext, pod, info.Node().Name)
+		if !status.IsSuccess() && status.Code() != framework.Unschedulable {


we should use !status.IsUnschedulable() not status.Code() == framework.Error because Success and Unschedulable* are the only two valid statues that we expect from filters, all other statuses should be considered errors.

ahg-g · 2019-08-29T14:33:48Z

pkg/scheduler/core/generic_scheduler.go

 	}

-	return len(failedPredicates) == 0, failedPredicates, nil
+	return true, failedPredicates, status, nil


lines 682-686 should be replaced with:

fit := len(failedPredicates) == 0 && status.IsSuccess() return fit, failedPredicates, status, nil

SGTM, DONE thanks！

ahg-g · 2019-08-29T14:37:45Z

pkg/scheduler/core/generic_scheduler.go

@@ -676,9 +671,19 @@ func podFitsOnNode(
 				}
 			}
 		}
+
+		// Iterate each plugin to verify current node


please remove this comment, it does not read well.

ahg-g · 2019-08-29T14:47:21Z

pkg/scheduler/core/generic_scheduler.go

+					filteredNodesStatuses[nodeName] = status
+				} else {
+					failedPredicateMap[nodeName] = failedPredicates
+				}


we should add both:

if !status.IsSuccess() { filteredNodesStatuses[nodeName] = status } if len(failedPredicates) { failedPredicateMap[nodeName] = failedPredicates }

k8s-ci-robot · 2019-08-30T18:28:29Z

@ahg-g: You must be a member of the kubernetes/milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility.

In response to this:

/milestone v1.16

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

ahg-g · 2019-08-30T18:29:21Z

@k82cn can you please add milestone 1.16 for this one as well? this is a bug fix.

alculquicondor · 2019-08-30T18:33:06Z

You can rebase now

wgliang · 2019-08-31T10:16:17Z

You can rebase now

Ok, done

k82cn · 2019-09-02T06:12:45Z

/milestone v1.16

alculquicondor · 2019-09-03T13:48:59Z

Implementation LGTM. Let's just add the regression test.

alculquicondor · 2019-09-05T13:31:21Z

/lgtm

ahg-g · 2019-09-05T13:39:06Z

pkg/scheduler/core/generic_scheduler_test.go

@@ -1119,14 +1119,31 @@ var startTime20190107 = metav1.Date(2019, 1, 7, 1, 1, 1, 0, time.UTC)
 // that podsFitsOnNode works correctly and is tested separately.
 func TestSelectNodesForPreemption(t *testing.T) {
 	defer algorithmpredicates.SetPredicatesOrderingDuringTest(order)()
+
+	filterPluginRegistry := framework.Registry{filterPlugin.Name(): NewFilterPlugin}


we faced problems in the past when using shared variables for the plugin instances, it would be great if we can change the way we instantiate plugins to be similar to what we did in integration tests:

define a generic function for instantiation:

// newPlugin returns a plugin factory with specified Plugin. func newPlugin(plugin framework.Plugin) framework.PluginFactory { return func(_ *runtime.Unknown, fh framework.FrameworkHandle) (framework.Plugin, error) { return plugin, nil } }

and here, you can just do:

filterPlugin := &FilterPlugin{} registry := framework.Registry{filterPluginName: newPlugin(filterPlugin)}

The above should allow you to remove the global instance filterPlugin

guineveresaenger · 2019-09-05T17:24:41Z

@ahg-g @alculquicondor @wgliang

I'm the Release Lead Shadow for 1.16 release.

This is an outstanding 1.16 PR and needs to be merged before EOD Monday 9/9 in time for our rc cut.

It looks like according to @ahg-g 's review that this isn't actually marked lgtm? Can someone update with an expected time of completion? Thank you! ❤️

alculquicondor · 2019-09-05T18:02:02Z

It looks like according to @ahg-g 's review that this isn't actually marked lgtm? Can someone update with an expected time of completion? Thank you!

Exactly, @wgliang is going to handle the latest minor suggestion

/lgtm cancel

guineveresaenger · 2019-09-05T22:25:17Z

do you have a reasonable notion of when thiswill be done, @alculquicondor? one thing that's missing is an Approver, it might be helpful to find someone so we can 🚢 it!

ahg-g · 2019-09-05T22:34:10Z

I can approve it.

wgliang · 2019-09-06T01:52:49Z

/retest

wgliang · 2019-09-06T02:07:50Z

@ahg-g @alculquicondor
Already updated all comments. Thank you for your review. :)

ahg-g · 2019-09-06T13:05:01Z

/lgtm
/approve
Thanks @wgliang

k8s-ci-robot · 2019-09-06T13:05:44Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahg-g, wgliang

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~pkg/scheduler/OWNERS~~ [ahg-g]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

k8s-ci-robot requested review from hex108 and Huang-Wei August 24, 2019 00:40

wgliang force-pushed the bugfix/filter-plugins-are-not-been-called-during-preemption branch 2 times, most recently from 5a62ce6 to 8cc86ce Compare August 24, 2019 02:26

draveness suggested changes Aug 24, 2019

View reviewed changes

wgliang force-pushed the bugfix/filter-plugins-are-not-been-called-during-preemption branch 2 times, most recently from c296483 to 7fb9e23 Compare August 25, 2019 23:47

alculquicondor reviewed Aug 26, 2019

View reviewed changes

ahg-g reviewed Aug 27, 2019

View reviewed changes

alculquicondor mentioned this pull request Aug 27, 2019

[Framework] Add UnschedulableAndUnresolvable status code #82034

Merged

wgliang force-pushed the bugfix/filter-plugins-are-not-been-called-during-preemption branch 2 times, most recently from cd2333d to f078b59 Compare August 29, 2019 09:08

wgliang mentioned this pull request Aug 29, 2019

Take the context as the first argument of Schedule #82119

Merged

alculquicondor reviewed Aug 29, 2019

View reviewed changes

ahg-g reviewed Aug 29, 2019

View reviewed changes

wgliang force-pushed the bugfix/filter-plugins-are-not-been-called-during-preemption branch from f340772 to 6da5f9e Compare August 31, 2019 00:15

k8s-ci-robot added this to the v1.16 milestone Sep 2, 2019

wgliang force-pushed the bugfix/filter-plugins-are-not-been-called-during-preemption branch from 6da5f9e to 892ddf5 Compare September 5, 2019 12:15

k8s-ci-robot assigned alculquicondor Sep 5, 2019

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Sep 5, 2019

ahg-g reviewed Sep 5, 2019

View reviewed changes

k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Sep 5, 2019

Fix filter plugins are not been called during preemption

d84a75c

wgliang force-pushed the bugfix/filter-plugins-are-not-been-called-during-preemption branch from 892ddf5 to d84a75c Compare September 6, 2019 01:59

k8s-ci-robot assigned ahg-g Sep 6, 2019

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Sep 6, 2019

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 6, 2019

k8s-ci-robot merged commit c58767b into kubernetes:master Sep 6, 2019

alculquicondor mentioned this pull request Sep 9, 2019

Nominate alculquicondor to scheduler reviewers #82500

Merged

xmudrii mentioned this pull request Oct 2, 2019

Rework the Bug Triage handbook kubernetes/sig-release#807

Merged

	if fits, _, err, _ := podFitsOnNode(pluginContext, pod, meta, nodeInfoCopy, fitPredicates, queue, false, filterPluginsFunc); !fits {
	if fits, _, _, err := podFitsOnNode(pluginContext, pod, meta, nodeInfoCopy, fitPredicates, queue, false, filterPluginsFunc); !fits {

Fix filter plugins are not been called during preemption #81876

Fix filter plugins are not been called during preemption #81876

Conversation

wgliang commented Aug 24, 2019

wgliang commented Aug 24, 2019

draveness left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

draveness Aug 25, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hex108 commented Aug 24, 2019

draveness commented Aug 24, 2019 • edited Loading

draveness commented Aug 24, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ahg-g left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

draveness Aug 25, 2019 •

edited

Loading

draveness commented Aug 24, 2019 •

edited

Loading