Zinnia started -> {Spark,Voyager} started #327
Conversation
|
@bajtos hindsight please |
| source: event.module | ||
| }) | ||
| break | ||
|
|
||
| case 'activity:error': | ||
| onActivity({ | ||
| type: 'error', | ||
| message: event.message.replace(/Module Runtime/, 'Zinnia'), | ||
| message: | ||
| event.message.replace(/Module Runtime/, capitalize(module)), |
There was a problem hiding this comment.
FWIW, these checks will break after we integrate filecoin-station/zinnia#470
It makes me wonder whether we should make a bigger change in the current design:
- push these "{module} started" messages from Zinnia/Core to individual modules
- remove the generic "Zinnia started" message completely
WDYT?
There was a problem hiding this comment.
Another option: Instead of working with strings, objectify these events into new type:
{ type: activity:start }
That should be enough for this case
There was a problem hiding this comment.
It's a great idea to use a new event type 👍🏻
Do you think it should be Zinnia or the module that reports this new event?
There was a problem hiding this comment.
I'm not sure. For consistency it would be better if Zinnia emits it. Otoh it's less semantic, as it only means "I have finished my process startup". If the module does it, it can potentially delay until it has finished all its necessary initialization.
There was a problem hiding this comment.
In the future, I'd like one zinniad process to run multiple modules. In that future, I can imagine having both events: "module runtime started" and "Spark started"/"Voyager started".
For now, I think the simplest option is to add this event to zinniad, because then we don't have to expose a new activity API to the JavaScript side.
It may be enough to make print_event() function public
https://github.com/filecoin-station/zinnia/blob/d0d12693f565574e2d286b79eb397a6f8f104e3a/daemon/station_reporter.rs#L65-L72
Then change this line to call print_event() instead of log_info_activity()
https://github.com/filecoin-station/zinnia/blob/d0d12693f565574e2d286b79eb397a6f8f104e3a/daemon/main.rs#L59
IIRC, we have two kinds of events - one for the runtime, another for the module(s). Events reported by the runtime come with module: null. I would use this mechanism for the start event printed by the runtime.
Otherwise: