Repository navigation
Conversation
3636308 to
bdc30df
Compare
a039e4a to
c34efc5
Compare
Previously, we resolved cubby numbers as job targets at execution time, using the server's currently available cubby map. The problem is that soon after boot, that cubby map is still empty, and so the server silently skipped jobs that named its cubby. In addition, a job that targeted a sled that was down or absent at job submission time could run whenever that sled later rejoined, perhaps quite a lot later (#75). With this change, job targets are resolved once up front by the accepting sled. It filters out the sleds it doesn't have a link to, and gossips the resolved targets with the job start request. Each sled checks that the signed target matches the gossiped target. Jobs that name an unreported cubby or have no reachable sled are refused. Starting a job now returns the sleds it will run on. The client reports any named sled the job will not run on, and a waiting client or server waits for exactly those sleds. Fixes #75. Co-authored-by: Claude <noreply@anthropic.com>
c34efc5 to
0f19416
Compare
plaidfinch
left a comment
plaidfinch
left a comment
There was a problem hiding this comment.
Why do we resolve the cubby on the receiving sled, rather than in the switch zone proxy? I don't think it functionally matters, so I think this is fine, but I thought I'd ask anyhow.
It doesn't much matter, but the main reason is that the proxy can't see the live gossip links, which we use to compute the resolved set of sleds. So the accepting sled would have to do all the same work anyway. |
Good enough reason for me! |
Previously, we resolved cubby numbers as job targets at execution time, using the server's currently available cubby map. The problem is that soon after boot, that cubby map is still empty, and so the server silently skipped jobs that named its cubby. In addition, a job that targeted a sled that was down or absent at job submission time could run whenever that sled later rejoined, perhaps quite a lot later (#75).
With this change, job targets are resolved once up front by the accepting sled. It filters out the sleds it doesn't have a link to, and gossips the resolved targets with the job start request. Each sled checks that the signed target matches the gossiped target. Jobs that name an unreported cubby or have no reachable sled are refused.
Starting a job now returns the sleds it will run on. The client reports any named sled the job will not run on, and a waiting client or server waits for exactly those sleds.
Fixes #75.