ADR 50: Install a Backing Broker for Knative Eventing

[skoved]

This ADR is to propose that Konflux pick a backing broker implementation for Knative Eventing.

Before this ADR is accepted: Konflux needs to decide whether to use Kafka or RabbitMQ

[adambkaplan]

We should be opinionated here, and my vote is to provision Apache Kafka using the Kafka Knative Broker.

Whether or not we choose Kafka or RabbitMQ, this will introduce additional dependencies to provision the underlying message queue infrastructure:

• Kafka: recommended approach is the Strimzi Operator
• RabbitMQ: recommended approach is the RabbitMQ Cluster operator and Message Topology Operator

Supporting both would add a lot of complexity to the current deployment repo. Let's pick one and get it working. I want to say that the current community has stronger experience using Kafka than RabbitMQ.

[skoved]

Supporting both would add a lot of complexity to the current deployment repo. Let's pick one and get it working

I agree that is why I added

Before this ADR is accepted: Konflux needs to decide whether to use Kafka or RabbitMQ

to the description for this PR. My intention was that after this ADR is discussed, I would remove which ever one was not selected.

[gbenhaim]

@adambkaplan kubearchive isn't a must for running konflux, thus I don't expect to include any broker as part of konflux-ci/konflux-ci

@skoved I think that the decision which broker to use is not related to upstream konflux because of the reason I mentioned above.

[adambkaplan]

kubearchive isn't a must for running konflux, thus I don't expect to include any broker as part of konflux-ci/konflux-ci

I think this comment also touches on the challenges we are having with the GitOps ADR (see #240) and the purpose of the konflux-ci/konflux-ci repo. We have learned the hard way that running a build system at scale requires extra components that consume significant compute resources. This creates a barrier to entry for adopters/evaluators who would like to experiment on a single computer or virtual machine.

I think we do need a home for these extras in the konflux-ci GitHub organization - not just code, but also a means to deploy them with an accepted definition.

[adambkaplan]

We also have a need for external parties to trigger releases (and have Konflux trust the content to be released). Exposing a message queue to receive such trigger events was requested. See KONFLUX-8689

[ralphbean]

Some notes from the @konflux-ci/kgc discussion on this:

• This was submitted before our new process. We're following up on it now.
• We recognize that this is trying to address a gap, but we're not sure an ADR is the right venue.
• We heard that kubearchive has a controller-mode feature which may make this ADR less relevant.
• In any case, the upstream installer doesn't currently install add-ons (other than image-controller). How will this ADR be implemented, in practice?

@skoved do you think it still makes sense to pursue this as an ADR?

[skoved]

Some notes from the @konflux-ci/kgc discussion on this:

* This was submitted before our new process. We're following up on it now.

* We recognize that this is trying to address a gap, but we're not sure an ADR is the right venue.

* We heard that kubearchive has a controller-mode feature which may make this ADR less relevant.

* In any case, the upstream installer doesn't currently install add-ons (other than image-controller). How will this ADR be implemented, in practice?

@skoved do you think it still makes sense to pursue this as an ADR?

I created this PR before we started working on "controller mode" on kubearchive. Now that we have "controller mode" I do not think that it makes sense to pursue this ADR at this time. I think it is safe to close

[skoved]

reopened per request by @ggallen