ADR 39: Propose an ADR to install Knative Eventing

[skoved]

This would not need to be done on Konflux production clusters yet, but at least installing knative eventing on testing clusters will allow integration to start if and when Konflux decides to integrate with KubeArchive

[skoved]

I've update the ADR to (hopefully) provide more clarity about why I'm proposing to have konflux install Knative Eventing and what Knative Eventing provides. This came from feedback during the community architecture call earlier today. I've also added additional details to what I think the consequences of installing Knative Eventing might be

[cit1zen]

Serverless-eventing is one of the technologies we look into as a possible future basis of MintMaker (dependency management).

I think having it available in some form could open doors to considerable performance and resource utilization improvements across Konflux, especially after people earn some experience. This option becomes part of the architecture design possibilities when designing new features or redesigning existing ones.

[skoved]

It's been a while since anything has happened on this PR, but I was busy with KubeArchive stuff in the second half of July and all of August.

I've updated the ADR to reflect the intent of this ADR as mentioned by @brianwcook at the July 16th Architecture meeting. My understanding of it is as follows.

To consider the usage of Knative-Eventing in Konflux separately from KubeArchive and determine if the usage of Knative-Eventing could make sense in Konflux.

If you believe that this is incorrect or incomplete, I'm willing to discuss this and update the ADR as needed. I would also appreciate if those involved in the discussion would take another look. I'm also willing to bring this as a topic for the architecture call again if folks think that it is necessary/helpful.

[ralphbean]

Although we don't have it in the architecture repo docs yet, I think we are happy to use some new terms to put some boundaries around different parts of konflux:

• Konflux core - these are components that you can assume are always installed in an instance of konflux. Other components can always depend on them being present. Example, tekton.
• Konflux add-ons - these are components that may or may not be installed in an instance of konflux. Other components can depend on them being present, but they must also have defined behavior for when they are not present. Example: mintmaker.
• Konflux integrations - these are systems external to Konflux that some Konflux components may refer to, if so configured. Example: trustification. If configured, the Konflux UI will link to SBOMs in a trustification UI somewhere else.

What would the # Decision section look like here if written in those terms? Are we saying one of the following things?

• knative eventing is a konflux add-on. It might be installed. If installed, other add-ons can take advantage of it. Nothing in core is allowed to depend on it.
• knative eventing is in konflux core. It will always be installed, and everything is permitted to depend on it.
• knative eventing is in konflux core, and all subsystems must refactor themselves to depend on it.

[skoved]

knative eventing is in konflux core, and all subsystems must refactor themselves to depend on it.

I want to make clear that this is NOT what this ADR is proposing. It is not the goal to force anyone to use Knative-Eventing

With that out of the way:

What would the # Decision section look like here if written in those terms? Are we saying one of the following things?

* knative eventing is a konflux add-on. It might be installed. If installed, other add-ons can take advantage of it. Nothing in core is allowed to depend on it.

* knative eventing is in konflux core. It will always be installed, and everything is permitted to depend on it.

This is something that I was thinking about, but I'm not sure that I can answer this myself. I'm not developing for konflux (directly) and I don't have any decision making power for the architecture and direction for Konflux. I'm hopeing that this ADR can start that discussion.

I assume that baring any other decisions that get made in the future, Knative-Eventing will be installed where ever KubeArchive gets installed. My assumption is that since KubeArchive would replace Tekton Results, KubeArchive and Knative-Eventing as a dependency for KubeArchive, would fit into the same category that Tekton Results inhabits currently. The only way I would see this changing is if, for the sake of argument (idk if this is actually the case in Konflux today) Tekton Results is in the Konflux add-ons or Konflux integrations group, Konflux makes the decision that it could be useful to have Knative-Eventing available and then promote Knative-Eventing into Konflux core. In this comment I list potential benefits to Knative-Eventing, but since I'm not directly involved in Konflux development, I cannot point to specific places in Konflux core that could benefit directly from Knative-Eventing. Based on the comment from @cit1zen it seems like MintMaker would be interested in Knative-Eventing if it was made available. I'm not sure which category MintMaker is in though

[ralphbean]

So, (this is up for debate) I think we want KubeArchive to be a Konflux add-on. It might be installed in an instance of Konflux, or it might not. If it is installed, then the UI can be configured to query it for old archived resources.

Today, I think tekton-results may actually be in konflux core, but (and this is up for debate) I think we may want to push it out to be a konflux add-on.

If we assume KubeArchive is an add-on, then I think we should start with the minimalist position of characterizing Knative Eventing as an add-on, and (simply) a dependency of KubeArchive. None of the core component would be permitted to depend on it. Mintmaker may depend on it, if that team chooses; it is also an optional add-on.

[gbenhaim]

Additional concern that I have is that the in memory channel shouldn't be used for production purposes, so it would require users to also get a Kafka instance, and I would really prefer not to have hard dependency on Kafka.

[pierDipi]

Hi everyone, I'm from Serverless/Knative Eventing team.

What I've read as concerns/points of discussions so far is:

1. Even unused features are using resources in dev clusters, konflux is beefy enough with mandatory parts IMO.

For 1) we have specific configurations to deploy only what you exactly need and we can help you with setting that up so that resource usage is as minimal as possible for your use cases and we might even do this automatically in the future.

2. Additional concern that I have is that the in memory channel shouldn't be used for production purposes, so it would require users to also get a Kafka instance, and I would really prefer not to have hard dependency on Kafka.

For 2), while that's currently true if you plan to use Broker and Triggers and have reliable distributed persistence, to use only event sources, you can just use Eventing with no other dependencies. Related questions are: is Kafka and operating Kafka the problem or generally having another dependency? would you be more comfortable with a different system to store events? and if so, which one?

I can't comment on other use cases and whether Eventing is a good fit for other core Konflux use cases as I don't know the specifics, however, I believe having the platform evolve and rely on events will make the platform much more reliable and scalable in the long run, especially since the Eventing runtime interface is just an HTTP POST request with a couple of extra standardized metadata/headers (CloudEvents), so consuming and producing services are very decoupled from specific implementation details and can be deployed and tested independently.

I don't want to hijack the conversation but feel free to reach out to us for any questions on #forum-serverless Slack or serverless-dev mailing list / group.

[gbenhaim]

2. Additional concern that I have is that the in memory channel shouldn't be used for production purposes, so it would require users to also get a Kafka instance, and I would really prefer not to have hard dependency on Kafka.

For 2), while that's currently true if you plan to use Broker and Triggers and have reliable distributed persistence, to use only event sources, you can just use Eventing with no other dependencies. Related questions are: is Kafka and operating Kafka the problem or generally having another dependency? would you be more comfortable with a different system to store events? and if so, which one?

@pierDipi yes my concern is requiring a potential Konflux user to also maintain/use managed Kafka instance. If there is a lighter backed that can be used it would be great.