Adjust service chain ownership when reassigning services between workers#5435
Conversation
| added_at: BlockHeight, | ||
| }, | ||
| // -- Messages sent from the workers to the controller chain -- | ||
| HandoffStarted { |
There was a problem hiding this comment.
Would it be possible to have a (mermaid?) diagram with all the messages? I understand we have 5 chains in 3 locations :)
There was a problem hiding this comment.
Actually, does it work if chains have several workers? (I believe the data structures allow it)
There was a problem hiding this comment.
Generally I tried to avoid assuming a single worker per service, since as you're saying, data structures allow multiple workers, but I also wasn't trying very hard to make it work in that case because of a comment in the controller that we should only use one worker per service for now. I actually believe this should work even with multiple workers, but I haven't tested it.
There was a problem hiding this comment.
I'm asking because in the case of a single worker per chain, it seems like we could remove HandoffStarted and have worker A directly send Start to worker B. But of course, it's interesting to be future-proof.
There was a problem hiding this comment.
I guess even with multiple workers, the controller could include the list of new workers to be notified after the owners are added in the Stop message 🤔
ma2bd
left a comment
ma2bd
left a comment
There was a problem hiding this comment.
Nice work! Added a couple of questions
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The Start and Stop messages now carry handoff-related fields. Update the service assignment, service removal, and messages table to match the code. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Please next time link the PR to the github issue in the proper way |
|
Ah, right, sorry! |
ma2bd
left a comment
ma2bd
left a comment
There was a problem hiding this comment.
We discussed some variations on the idea but this could also be experimented on a different PR
…tween workers (#5435) (#5506) ## Motivation If a service is reassign from worker A to worker B by the controller application, worker A should cease to be the owner of the service's chain, and worker B should become an owner. ## Proposal Upon reassignment, when telling worker A to stop running the service, worker A will add worker B as an owner and notify the main controller chain. The main controller will then tell worker B to take over, telling it at which height on the service chain it became an owner. Worker B then waits until it synchronizes the service chain until that height, and when it's ready, it starts listening to the chain in FullChain mode and removes worker A as an owner. ## Test Plan `test_controller` was extended to reassign a service from one worker to another, and then check if the second worker properly handles a task request. ## Release Plan - These changes should be released in a new SDK ## Links - Backported PR: #5435 - [reviewer checklist](https://github.com/linera-io/linera-protocol/blob/main/CONTRIBUTING.md#reviewer-checklist) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2 participants
Motivation
If a service is reassign from worker A to worker B by the controller application, worker A should cease to be the owner of the service's chain, and worker B should become an owner.
Proposal
Upon reassignment, when telling worker A to stop running the service, worker A will add worker B as an owner and notify the main controller chain.
The main controller will then tell worker B to take over, telling it at which height on the service chain it became an owner. Worker B then waits until it synchronizes the service chain until that height, and when it's ready, it starts listening to the chain in
FullChainmode and removes worker A as an owner.Test Plan
test_controllerwas extended to reassign a service from one worker to another, and then check if the second worker properly handles a task request.Release Plan
testnetbranch, thenLinks