Konflux should emit cloud events. #206
Conversation
ggallen
force-pushed
the
emit-cloud-events
branch
from
edf316a
to
0a9ff71
Compare
There was a problem hiding this comment.
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.
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. |
| To support this, all Konflux components should be required to emit cloud events for signicant events. These | ||
| should be documented fully and made available for users. | ||
|
|
||
| Cloud event generation could be optional and that option could default to off. But users should be able to |
There was a problem hiding this comment.
This probably needs clarification on what "users" are. I'm assuming this is a Konflux deployment admin, and not a user that uses Konflux to build content.
There was a problem hiding this comment.
From async conversation - I think Greg means for this to be end-users. I.e., the developers that use Konflux to build, test and release their software. He doesn't mean platform engineers (the people running a konflux instance) or other konflux controllers.
| they can use these cloud events to create their own product-specific infrastructure to support their build | ||
| and release process. | ||
|
|
||
| To support this, all Konflux components should be required to emit cloud events for signicant events. These |
There was a problem hiding this comment.
Let's consider if "should be required to emit" is too strong of a statement. I believe "should emit" better describes the intent.
| Konflux should not emit cloud events. | ||
|
|
||
| Emitting cloud events would allow Konflux users to easily track what is happening in the system. In addition, | ||
| they can use these cloud events to create their own product-specific infrastructure to support their build |
There was a problem hiding this comment.
Can we use a different term other than "product-specific" throughout this document? AFAIK, Konflux is not aware of what a product is. Maybe use "application-specific"?
There was a problem hiding this comment.
or even "team-specific" or "org-specific"
However, the ADR mentions:
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. |
|
|
||
| ## Consequences | ||
|
|
||
| Product teams can more easily build product-specific build and release infrastructure in Konflux. |
There was a problem hiding this comment.
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?
|
Some notes from the architecture call today.
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). |
|
|
||
| ## Consequences | ||
|
|
||
| Product teams can more easily build product-specific build and release infrastructure in Konflux. |
There was a problem hiding this comment.
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.
|
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?" |
No description provided.