Skip to content
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

dispatcher: Always send task updates to agent when state <= ASSIGNED #1295

Merged
merged 1 commit into from
Aug 2, 2016

Conversation

aaronlehmann
Copy link
Collaborator

The use of TaskEqualStable in the dispatcher to avoid sending
unnecessary task updates is problematic for global services. These tasks
only move to the ASSIGNED state once the scheduler confirms resources
are available. Since state changes are not considered relevant changes
and do not trigger assignment set updates, the dispatcher may never send
this update, and tasks can become stuck in the ASSIGNED state.

If a task is in the state ASSIGNED or below, always count a state change
as a modification, even if nothing else has changed.

Fixes #1291

I know this isn't the cleanest solution, but it seems like the simplest and lowest risk approach for 1.12.1. We can try to find something better for 1.13.

cc @dongluochen @aluzzardi

The use of TaskEqualStable in the dispatcher to avoid sending
unnecessary task updates is problematic for global services. These tasks
only move to the ASSIGNED state once the scheduler confirms resources
are available. Since state changes are not considered relevant changes
and do not trigger assignment set updates, the dispatcher may never send
this update, and tasks can become stuck in the ASSIGNED state.

If a task is in the state ASSIGNED or below, always count a state change
as a modification, even if nothing else has changed.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
@codecov-io
Copy link

Current coverage is 55.08% (diff: 100%)

Merging #1295 into master will increase coverage by 0.18%

@@             master      #1295   diff @@
==========================================
  Files            78         78          
  Lines         12467      12467          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           6844       6867    +23   
+ Misses         4674       4658    -16   
+ Partials        949        942     -7   

Sunburst

Powered by Codecov. Last update 38468bd...4965ffc

@dongluochen
Copy link
Contributor

LGTM

1 similar comment
@LK4D4
Copy link
Contributor

LK4D4 commented Aug 2, 2016

LGTM

@LK4D4 LK4D4 merged commit f1d2775 into moby:master Aug 2, 2016
@aaronlehmann aaronlehmann deleted the send-assigned-tasks branch August 2, 2016 17:29
@aluzzardi
Copy link
Member

Soooo ... It made sense to create an equality package because those two comparisons will always be the same, right? :P

@@ -595,7 +595,10 @@ func (d *Dispatcher) Tasks(r *api.TasksRequest, stream api.Dispatcher_TasksServe
modificationCnt++
case state.EventUpdateTask:
if oldTask, exists := tasksMap[v.Task.ID]; exists {
if equality.TasksEqualStable(oldTask, v.Task) {
// States ASSIGNED and below are set by the orchestrator/scheduler,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the task is not ASSIGNED, how can we send it to an agent?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the task is not ASSIGNED, how can we send it to an agent?

This is a fair point. Filtering out these tasks would be a behavioral change, though. The aim of this PR is just to make sure the agent is notified when a task transitions into ASSIGNED.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is not what I mean. If a task is not assigned, we cannot send it to a node, since it doesn't have an assignment.

I mean, this should be impossible.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

task.NodeID is set before the task reaches the ASSIGNED state for global services.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

task.NodeID is set before the task reaches the ASSIGNED state for global services.

So, if the NodeID is set, the task should be assigned.

We can't break these kinds of invariants, even if it means having a second field indicating that a task was created for assignment to a specific node. It makes making logical decisions hard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants