-
Notifications
You must be signed in to change notification settings - Fork 178
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
chore(api, robot-server): Manage runners via run orchestrator #15190
Conversation
@@ -126,32 +120,32 @@ def __init__( | |||
self._robot_type = robot_type | |||
self._deck_type = deck_type | |||
self._default_engine: Optional[ProtocolEngine] = None | |||
self._runner_engine_pair: Optional[RunnerEnginePair] = None | |||
hardware_api.register_callback(_get_estop_listener(self)) | |||
|
|||
@property | |||
def engine(self) -> ProtocolEngine: |
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.
wanted to change this to a get method instead of a property now that its a property of the orchestrator but bc its a store it dosent really match?
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 think it’s fine to keep it as a property since in theory this will go away in favor of something that returns the orchestrator
@property | ||
def runner(self) -> AnyRunner: | ||
"""Get the "current" persisted ProtocolRunner.""" | ||
return self._protocol_runner or self._setup_runner |
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.
Will this property's return value need to change intelligently between runners depending on the run state? Like, it returns self._setup_runner
while the run is in the setup phase, and self._fixit_runner
while error recovery is active, and self._protocol_runner
otherwise? Or am I misunderstanding the plan?
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.
thats not a bad idea. I was thinking about this more like:
if there is a protocol runner always return that, if there is no protocol runner then fixit_runner is not active and we are only able to use setup runner but! this property will probably vanish bc we are going to remove access directly with the runner and let the orchestrator handle the logic. let me know if this makes sense.
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.
Yeah I think this property goes away forever and the orchestrator itself offers semantically relevant api, like a method called run_setup_command and a method called run_fixit_command
601e5ec
to
b63f97c
Compare
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.
Functionality looks good but let’s get those comments cleaned up! Great first step.
@property | ||
def runner(self) -> AnyRunner: | ||
"""Get the "current" persisted ProtocolRunner.""" | ||
return self._protocol_runner or self._setup_runner |
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.
Yeah I think this property goes away forever and the orchestrator itself offers semantically relevant api, like a method called run_setup_command and a method called run_fixit_command
@@ -126,32 +120,32 @@ def __init__( | |||
self._robot_type = robot_type | |||
self._deck_type = deck_type | |||
self._default_engine: Optional[ProtocolEngine] = None | |||
self._runner_engine_pair: Optional[RunnerEnginePair] = None | |||
hardware_api.register_callback(_get_estop_listener(self)) | |||
|
|||
@property | |||
def engine(self) -> ProtocolEngine: |
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 think it’s fine to keep it as a property since in theory this will go away in favor of something that returns the orchestrator
else None | ||
) | ||
|
||
# TODO(tz, 2024-5-14): probably dont need this once its all redirected via orchestrator |
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.
Definitely will - there will need to be a different default_orchestrator that has a different engine and probably only setup and fixit runners
2f18907
to
91c8a13
Compare
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.
Nice!
Overview
part of https://opentrons.atlassian.net/browse/EXEC-418.
create RunOrchestrator provider to manage, engine->runners scope.
this tickets is just to introduce the term and redirect calls via the orchestrator.
Test Plan
Changelog
Review requests
do we feel good about these changes?
Risk assessment
low. redirecting calls via orchestrator but structure stayed the same.