Live Runner + Scope support#20
Conversation
The new runner uses `address` as an opaque blob
Registers the app as a runner with an orchestrator.
Also make price info optional
None of these have anything to do with orchestrators. Keep only small shims for backwards compatibility.
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
|
|
||
| async def _maybe_await(value: object) -> None: | ||
| if inspect.isawaitable(value): | ||
| await value |
|
|
||
| async def _maybe_await(value: None | Awaitable[None]) -> None: | ||
| if inspect.isawaitable(value): | ||
| await value |
| if wait_callback and (timeout is None or timeout > 0): | ||
| try: | ||
| await self.wait_callback(timeout=timeout) | ||
| except asyncio.TimeoutError: |
| if wait_callbacks and (timeout is None or timeout > 0): | ||
| try: | ||
| await self.wait_callbacks(timeout=timeout) | ||
| except asyncio.TimeoutError: |
| task.cancel() | ||
| try: | ||
| await task | ||
| except asyncio.CancelledError: |
| def _release_session_id(self, session_id: str) -> None: | ||
| try: | ||
| self._active_session_ids.remove(session_id) | ||
| except ValueError: |
|
|
||
|
|
||
| class LiveRunnerSessionHeaders(Protocol): | ||
| def get(self, key: str, default: str = "") -> str: ... |
| runner_url: str, | ||
| app: str, | ||
| price_per_unit: int = 0, | ||
| pixels_per_unit: int = 1, |
There was a problem hiding this comment.
@j0sh can we use something like unit_scale since this runner also allows different pricing schemes. Also see my pull request in go-liveper livepeer/go-livepeer#3942.
There was a problem hiding this comment.
I'll look into that idea (and the general move from away from pixels to purely timing) but don't want to block this merge for that
| secret: str, | ||
| runner_url: str, | ||
| app: str, | ||
| price_per_unit: int = 0, |
There was a problem hiding this comment.
@j0sh How do you intend pricing to work for dynamic runners? Right now the app self-asserts price_info via register_runner(price_per_unit=…) and go-livepeer trusts it (only > 0 is checked in normalizeHeartbeat). That's fine for operator-deployed/trusted containers — the operator sets the price via env and the app forwards it — but an untrusted image could ignore that and under-report its price. Static sidesteps this (operator sets price_info in runners.json); only dynamic trusts the app.
You can see how I'm currently using this in the hello_world example, which feels a bit strange since it relies on the app to create the argument and forward it.
Two thoughts:
- If the orchestrator is still meant to set the price in dynamic mode (to make gaming harder), the SDK could auto-read it from env (e.g. PRICE_PER_UNIT) instead of the app passing it to register_runner, keeping pricing a deployment/operator concern, out of app code.
- I think we'll eventually move to GPU-based pricing (orchestrator states a price per GPU type, workloads auto-run at that rate), so go-livepeer would override the reported price at registration anyway.
There was a problem hiding this comment.
That's correct, the runner itself reports the price because the orchestrator is intended to control the runner.
There was a problem hiding this comment.
This way runner provisioning (including pricing) can be configured separately from go-livepeer without having to introduce a mutual dependency on one other. Setting the price on go-livepeer itself introduces a tension with the orchestrator needing to be configured separately with details of the runner / workload, hardware, etc, as opposed to runners being able to simply connect and go.
If you want to keep the configuration / pricing within go-livepeer then static configuration is the way to go.
2 participants
No description provided.