Adding `Requested` event semantics to vocabulary about spec

[e-backmark-ericsson]

To me, an event like PipelineRunRequested (or maybe PipelineRunTriggered) could be added, which would mean that a pipeline execution has been put in a queue for execution. It sounds to me that what you're after is not really a queuing event, but an event that a pipeline executor would listen to to trigger a pipeline execution. I'd say that a pipeline execution could be triggered by multiple different events. Very common would be the source (created/reviewed/merged) events, but also the artifact published and service deployed events for example.

We can discuss this on the vocabulary meeting later today.

[salaboy]

@e-backmark-ericsson did you manage to discuss this with the group? unfortunately, I couldn't join last week.
Is there any chance for us to do a quick discussion on this ad-hoc from that bi-weekly meeting?

[afrittoli]

We have a PipelineRunQueued event already, which means that a PipelineRun has been requested but it did not start executed yet - it may be waiting on scheduling or in general resource availability.
Note that this event is generated by the pipeline orchestration engine, not by the system that would like the pipeline run to be executed.

We discussed in the past about declarative vs. imperative events (see my comment in cdfoundation/sig-events#107 (comment) also) and my understanding is that we settled for declarative events, where events are sent by a system to describe something that happens, as opposed to imperative events where a system sends an event to another one asking for something to be done.

With declarative events, if a system completes task1, it will send an event. Any system may react to that event by performing its own task2.

[m-linner-ericsson]

Looking at the CloudEvents spec https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md#terminology

An "event" is a data record expressing an occurrence and its context. ...

and

An "occurrence" is the capture of a statement of fact during the operation of a software system. This might occur because of a signal raised by the system or a signal being observed by the system, because of a state change, because of a timer elapsing, or any other noteworthy activity. ...

To me a Requested sounds like a command and would not fit with description here. It would probably also need a receiver or should all pipelines trigger on it?

My main concern with adding such events is that we enable to create a more coupled system and to me the point of events is to create a decouple system.

[e-backmark-ericsson]

I agree to what both Andrea and Mattias wrote. @salaboy , are we misinterpreting your need?

[e-backmark-ericsson]

@salaboy , based on the discussion we just had on the meetup. Could you elaborate on the use case a bit more to clarify what is missing from a "queued" event, that we already have a bunch of in the specification? I do see that it would be beneficial that both Queued, Started and Finished events are sent from the same source, but to me that should not be mandatory, as long as the events sent are descriptive rather than prescriptive.

[e-backmark-ericsson]

When trying to understand your use case, @salaboy , I drew this picture. Does it somewhat correspond to what you're after? If so, is it the "RequestDeployment" event you're missing?

[afrittoli]

@salaboy should we close this now, or is this something you're still interested into?

[e-backmark-ericsson]

Closing this issue, since no reply on it in a long time. If it is still relevant, please open a new issue about it.