ADR 41: Konflux should emit cloud events.

[ggallen]

No description provided.

[gbenhaim]

LGTM. I just want to mention that Tekton has a feature for emitting cloud event (https://tekton.dev/vault/pipelines-v0.50.x-lts/additional-configs/#configuring-cloudevents-notifications), so at least reacting to the Konflux' pipelineruns and taskruns is already possible today.

[ggallen]

so at least reacting to the Konflux' pipelineruns and taskruns is already possible today.

The functionality is there in Tekton, but I don't believe it is enabled by default. But one of the first things to do should this ADR be accepted is to turn on that functionality.

[lcarva]

Let's consider if "should be required to emit" is too strong of a statement. I believe "should emit" better describes the intent.

[scoheb]

I agree on the "softening"

[ggallen]

Why? I actually don't agree. This should be a requirement. If not, you end up with a system that has no consistency. Some tools may emit events while other do not. This does not make a for a consistent, or good, user experience.

The intent of the ADR is to have Konflux emit events for everything that makes sense.

[lcarva]

In this case, I do not agree with the ADR. It's too early to make such a call. We should first experiment with emitting some cloud events. Then, once the value has been proved, we can make a follow up ADR to actually apply this across the board.

[ggallen]

It's too early to make such a call.

To early in what sense?

Tekton already provides cloud events, so they have done this "experiment" and have determined it is worthwhile.

I am working on getting together some use cases.

[lcarva]

To early in what sense?

I'm thinking of the Konflux-specific components, e.g. release/integration service. I'd like to see things like that emitting cloud events for some time before requiring everything in Konflux to emit cloud events.

[lcarva]

The functionality is there in Tekton, but I don't believe it is enabled by default. But one of the first things to do should this ADR be accepted is to turn on that functionality.

However, the ADR mentions:

Cloud event generation could be optional and that option could default to off.

Are you talking about turning on that functionality on a specific deployment of Konflux? That is perhaps outside the scope of these ADRs. As I see it, these are about the Konflux project, not necessarily any one deployment of Konflux.

[ralphbean]

Can you add more to this section to make it more clear how, when, and why cloudevents would be used as opposed to extending build, test, or release pipelines?

[ggallen]

@ralphbean, please see the section of use cases that I just added.

[ralphbean]

Some notes from the architecture call today.

• It should be possible to turn this off (and perhaps default to off) for the upstream installer to keep the footprint small.
• Tekton already exposes CloudEvents. Turning that on should just be a configuration option that someone running the platform can do today.
• There was some confusion about who the target audience for CloudEvents is. After discussion in the call (and some more afterwards) the intended audience is the end-user; the developer using Konflux to build their software.
• There's a note already in the architecture constraints that says "Use tekton for anything that should be extended by the user (building, testing, releasing)." If the purpose here is to give the end user a way to extend the system, that line needs to be revised.
• If we're revising that constraint, then we need some explanation of why, when, and how a user would choose to use cloudevents rather than extend their build, test, and release pipelines.

Arguably, anything a user might do with cloudevents they might also be able to do by extending their build, test, or release pipelines. If the idea here is that using cloudevents can be simpler for that user, I'd like to see in the Consequences section some elaboration on how that will work (what resources does the user need to create to take advantage of this, what RBAC do they need to achieve this).

[ralphbean]

If this is a path we want to pursue, that likely entails UI support. If we recommend users extend our platform by way of cloudevents, then their sinks and triggers should all get some representation in the UI to visualize what they've assembled and its runtime status.

If that makes sense, then that deserves some elaboration in the Consequences section here.

[ggallen]

I don't envision the UI being involved here at all. The emission of cloud events just allows users to monitor and react to any event they deem important. It similar to a CLI, and in that case I wouldn't expect the UI to display anything about any client that uses the CLI.

[scoheb]

I think this ADR could benefit from the use cases or examples of situations where cloudevents would be helpful to users. What do you envision the users wanting to do?

I believe this would help with the question I ask myself ... "why not develop whatever feature the users is resorting to using cloudevents for?"

[ggallen]

Cloud event generation could be optional and that option could default to off.

Are you talking about turning on that functionality on a specific deployment of Konflux? That is perhaps outside the scope of these ADRs. As I see it, these are about the Konflux project, not necessarily any one deployment of Konflux.

Konflux should allow users to turn on or turn off the emission of cloud events. Turning it on would then turn on emitting cloud events in all Konflux components. The same for turning it off.

In other words, this should be provided as a Konflux configuration option, to be turned on or off in any Konflux deployment.

[ggallen]

I think this ADR could benefit from the use cases or examples of situations where cloudevents would be helpful to users. What do you envision the users wanting to do?

I believe this would help with the question I ask myself ... "why not develop whatever feature the users is resorting to using cloudevents for?"

@scoheb, I just added a section of use cases.