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

chore(api, robot-server): Manage runners via run orchestrator #15190

Merged
merged 51 commits into from
May 17, 2024

Conversation

TamarZanzouri
Copy link
Contributor

@TamarZanzouri TamarZanzouri commented May 15, 2024

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

  • uploading protocols and running them should not change
  • issuing commands without runs should not change

Changelog

  • Added RunOrchestrator provider to manage multiples runners with PE.
  • change engine_store runners/engine props to use RunOrchestrator instead.
  • create RunOrchestrator when creating a run.

Review requests

do we feel good about these changes?

Risk assessment

low. redirecting calls via orchestrator but structure stayed the same.

@@ -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:
Copy link
Contributor Author

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?

Copy link
Member

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

@TamarZanzouri TamarZanzouri marked this pull request as ready for review May 16, 2024 15:29
@TamarZanzouri TamarZanzouri requested a review from a team as a code owner May 16, 2024 15:30
Comment on lines +46 to +49
@property
def runner(self) -> AnyRunner:
"""Get the "current" persisted ProtocolRunner."""
return self._protocol_runner or self._setup_runner
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Member

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

@TamarZanzouri TamarZanzouri changed the title Exec 418 run orchestrator builder chore(api, robot-server): Manage runners via run orchestrator May 16, 2024
@TamarZanzouri TamarZanzouri force-pushed the EXEC-418-run-orchestrator-builder branch from 601e5ec to b63f97c Compare May 16, 2024 20:18
Copy link
Member

@sfoster1 sfoster1 left a 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.

Comment on lines +46 to +49
@property
def runner(self) -> AnyRunner:
"""Get the "current" persisted ProtocolRunner."""
return self._protocol_runner or self._setup_runner
Copy link
Member

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

api/src/opentrons/protocol_runner/run_orchestrator.py Outdated Show resolved Hide resolved
api/src/opentrons/protocol_runner/run_orchestrator.py Outdated Show resolved Hide resolved
@@ -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:
Copy link
Member

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
Copy link
Member

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

robot-server/robot_server/runs/engine_store.py Outdated Show resolved Hide resolved
@TamarZanzouri TamarZanzouri force-pushed the EXEC-418-run-orchestrator-builder branch from 2f18907 to 91c8a13 Compare May 17, 2024 16:40
Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

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

Nice!

@TamarZanzouri TamarZanzouri merged commit 6c75733 into edge May 17, 2024
20 checks passed
@TamarZanzouri TamarZanzouri deleted the EXEC-418-run-orchestrator-builder branch May 17, 2024 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants