Create event api

[krhubert]

No description provided.

[NicolasMahe]

you could change the message CreateEventRequest to:

message CreateEventRequest {
  // instanceHash is hash of instance that can proceed an execution.
  string instanceHash = 1;

   // key is the key of the event.
  string key = 2;

   // data is the data for the event.
  string data = 3;
}

So there is not need to check for a not empty hash in server/grpc/api/event.go

Also I think it's more logic to have different messages to create the resource and to return it.
The same modification should be done (but in a future time) on ServiceX/Create. Reusing the definition.service causes more problem than it solves.

[krhubert]

// The request's data for the `Create` API.
message CreateServiceRequest {
  definition.Service definition = 1; // The service definition to use to create the Service.
}

We accept service in servcie api, so I wanted to be consistent. And I prefer to check if hash is empty rather then redefine all event fields (same for CreateServiceRequest). It's more clear that CreateEventRquest expects event as argument.

[NicolasMahe]

The following issue is actually to change CreateServiceRequest: #1111

[NicolasMahe]

Suggested change

	func (e *Event) Emit(instanceHash hash.Hash, eventKey string, eventData map[string]interface{}) (*event.Event, error) {
	func (e *Event) Emit(evnt *event.Event) (error) {

what about changing the parameters of this function to directly accept the event struct?
I think it will make this function a bit simpler as well as the api package.

[antho1404]

It's fine like that, otherwise, we will still have the confusion between the actual inputs and the resource itself which is not good. We will have the same problem that we have with the service.create

[krhubert]

I'm ok with both - just another thing we can make consistent accross source code.

[NicolasMahe]

The function create in serviceSDK accept directly the service:

func (s *Service) Create(srv *service.Service) (*service.Service, error) {

[krhubert]

Can I upadte this when I'm going to remove coreapi methods?

[antho1404]

It's fine like that, otherwise, we will still have the confusion between the actual inputs and the resource itself which is not good. We will have the same problem that we have with the service.create