Open OpenCoderX opened 1 year ago
Interesting proposal! cc @rkooo567 @scottsun94
This sounds like customized key-value data on the actor - wondering if common libraries in AIR would benefit from such as well. cc @matthewdeng
There was a follow on thought to this proposal (a @dashboard_action' decorator that exposed the ability to execute a function on the actor), but the more I thought about it, it seemed overly complicated to include in this proposal.
Logically, once the dashboard operator knows the state of the actor based on the new customized key-value data, they might want to take some action. In my data ingestion scenario, I might want to 'Pause' the Actor. This new @dashboard_action decorator would allow the dashboard to call the decorated function from the dashboard. The name on the button on the Dashboard would be some humanized version of the function name.
This would leave the developer who implements the decorated function on their Actor to ensure that calling the action from the dashboard does not leave the Actor in an inconsistent/unrecoverable/hung state.
I posed this question originally here: https://discuss.ray.io/t/customizing-actor-dashboard-to-display-actor-state/9692
Hi, I'm a bot from the Ray team :)
To help human contributors to focus on more relevant issues, I will automatically add the stale label to issues that have had no activity for more than 4 months.
If there is no further activity in the 14 days, the issue will be closed!
You can always ask for help on our discussion forum or Ray's public slack channel.
Description
Introduce a decorator that exposes an attribute on an Actor class to the dashboard. This attribute will appear in a new column on the dashboard.
Use case
This will provide greater visibility into the Actor; any use case that involves a dashboard operator wondering what an Actor is doing would benefit from viewing the state of an attribute of the Actor class. For example, the Actor could represent a state machine; the developer could then expose that state and let the operator viewing the dashboard know what state the worker is in.
In my case, the Actor is the last stage of an ingestion pipeline; my ingestion pipeline has dedicated actors per database table. Each table can have N max actors operating against the table. I would use this new feature to expose the Actor's configuration parameters, most notably the table it is assigned to ingest into.