search

konflux-ci / architecture

Technical and Architecture documents
https://konflux-ci.dev/architecture/
18 stars 67 forks source link

Propose an ADR to install Knative Eventing #202

Open skoved opened 2 months ago

skoved commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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:

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

skoved commented 2 weeks ago

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 commented 2 weeks ago

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 commented 1 week ago

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.