Can one of the admins verify this patch?

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28841/
Test FAILed.

Some questions.

1. Is it still WIP? It seems like there are bunch of test failures now, so I assume it is the case?
2. Can you at least address all comments from the previous PR? We can re-review after that.

Some questions.

1. Is it still WIP? It seems like there are bunch of test failures now, so I assume it is the case?
2. Can you at least address all comments from the previous PR? We can re-review after that.

1. it is not WIP, it finished. Maybe there are some Lint errors. I will fix it and rebase the master.
2. Here are the comments in the previous PRs and my solutions

#9612 (comment)
It's OK to use the JSON format to write, I prepare to move this function to the subclass(next PR). And there is some question about how to deal with multiple lines.

#9612 (comment)
I have changed the event protobuf to support custom labels

#9612 (comment)
I am not very clear about this review. It is just our original design intention in Ant. Or do you mean there will be some automatic binding to report event?

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28933/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28934/
Test FAILed.

@Basasuya I meant address all comments in the previous PR! (so that Edward and Lingxuan doesn't need to have the same review). I just would like to have your confirmation, so that we can resume review after that (or reply here if you have questions). Also, thanks for your responses to my msgs!

I am not very clear about this review. It is just our original design intention in Ant. Or do you mean there will be some automatic binding to report event?

It was more like a question (not really a review). I am not super familiar with events, so I am not sure if my concern is valid. Also, I generally agree with the whole structures. It is just about how we record events.

Here was my thought process.

When I see description of what events are about, it gives me impression that events should

1. not have messages that are easily mutable.
2. not be abused. Each events should have a clear intention. Devs should not use events everywhere.
3. have hierarchy for searchability.

And it makes me feel like events should be pre-defined with description/schema. For example, when actors are created, we only need these events. Adding more is probably unnecessary.

ACTOR_CREATION(description="Actor creation process")

ACTOR REGISTRATION INITIATED (parent=ACTOR CREATION, sev=INFO, description="events that indicate actor registration process is initiated", actor_id="123")
DEPENDECY_RESOLVED (parent=ACTOR CREATION, sev=INFO, actor_id)
SCHEDULING REQUSET TO RAYLET (parent=ACTOR CREATION, sev=INFO, actor_id)
SCHEDULING CONFIRMED (parent=ACTOR CREATION, sev=INFO, actor_id)
CREATING ACTOR TO NODE (parent=ACTOR CREATION, sev=INFO, actor_id)
ACTOR CREATION FAILED (parent=ACTOR CREATION, sev=ERROR, actor_id)
ACTOR REGISTRATION DONE (parent=ACTOR CREATION, sev=INFO, actor_id)

// Sorry the syntax is weird, but it is how I imagine to use this. 
EVENT(DEPENDECY_RESOLVED(actor_id="")) << "msg"

Here are some problems I can imagine with the current APIs.

1. If someone changes messages, it can screw up the whole systems. For example, someone has an alert to "Actor restart" event, and if someone changes the string to "actor restart", alarm can be broken. It is also hard to make it backward compatible.
2. It is very hard to know the purpose of each events. / It is hard to search events.
3. It is super easy to abuse events. Someone can easily add events at unnecessary places.

@Basasuya I meant address all comments in the previous PR! (so that Edward and Lingxuan doesn't need to have the same review). I just would like to have your confirmation, so that we can resume review after that (or reply here if you have questions). Also, thanks for your responses to my msgs!

I don't know how to release all the reviews in the previous PR = =. Do you mean just copy these links?

LingXuan's
#9612 (comment)
#9612 (comment)
#9612 (comment)
#9612 (comment)
#9612 (comment)
#9612 (comment)
#9612 (comment)
#9612 (comment)

Edward's
#9612 (comment)
#9612 (comment)
#9612 (comment)

Sangbin's
#9612 (comment)
#9612 (comment)
#9612 (comment)
#9612 (comment)

#9657 (comment)

I think this question is about whether we need to make the event more structured. I think, first of all, the event call should be buried in the ray core carefully, not just like LOG. If you need to create a high-level API like ACTOR_CREATION, DEPENDECY_RESOLVED, and so on. it should be defined by the core_worker itself, This can be achieved by designing another layer above this event framework. Second, users may abuse this API, I think some tags can be set to distinguish these events (such as label). We can also use a method like the LOG severity level.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28967/
Test FAILed.

@Basasuya I agree we can build that abstraction in the higher layer. Also, I didn't mean to port those comments to here. I just meant "please make sure to address those comments in this PR!"

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/29076/
Test FAILed.

@Basasuya IIRC the previous PR was just to show the concept/API for this. Should I review this one assuming we're actually going to merge it?

@edoakes @rkooo567 Sorry for not replying to you these days. I have a deadline for paper revision in my Lab this week. Now it is finished. I will work on this PR from now on.

@Basasuya IIRC the previous PR was just to show the concept/API for this. Should I review this one assuming we're actually going to merge it?

Yes, we should discuss on this PR. This PR involves the basic level design of the event framework.

@raulchen @yuyiming welcome to review this PR

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/29646/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/29647/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/29649/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/29652/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/29662/
Test FAILed.

There's a lint failure.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/29675/
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/29705/
Test FAILed.

There's a lint failure.

fixed