Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,50 @@ Limitations:

- It is not currently possible to disable periodics per job

# Konflux

## Overview

In Konflux, an `Application` is a named group of `Component`s and a `Component` is ultimately a
release-able artifact, for example, a container image.
Generally, the definition of _group_, in this context, is not really strict since a component in one
application can reference and therefore depend on a component in another application (directly,
regardless of the application they use) as well as a repository, in particular, a branch of a
repository can have components with different appplications.

For `serverless-operator`, we use (primarily) regular container image components and (File-Based
Catalog) FBC components (also known as OLM catalog index images).
While this distinction is not evident in the `Component` API Spec nor in the `Application` API spec,
the difference is in the pipeline we run to build them. The pipelines are directly taken from the
shared [`konflux-ci/build-definitions`](https://github.com/konflux-ci/build-definitions) and then
we apply Kustomize [patches](./pkg/konfluxgen/kustomize) to configure them according to our needs.

When we were deciding the overall applications and components architecture we settled on having:

1. one application per OCP version for FBC components;
2. one application per major `serverless-operator` version, containing all the regular container
images;

For point 1), this is a requirement of the Konflux Release Service for releasing FBC components, for
point 2), we had more flexibility on how many applications and how to group components, but we
decided to use a single application for all the components for the following benefits:

- It's easier to automate the creation of the configurations as we would not need to distinguish
what belongs to which application.
- It's less fragmented, and we can attach full-product integration tests

// TODO more details on the alternatives

## Konflux configuration architecture diagram

The architecture of the Konflux configuration architecture is summarized in this diagram:
Copy link
Contributor

@skonto skonto Oct 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add some more info about design decisions made, so we may iterate on in the future? For example explain a bit the diagrams and any assumptions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add more details soon


![Konflux applications and components diagram](./docs/assets/konflux-serverless-operator-architecture.png)

while the following summarizes the Konflux release configuration architecture:

![Konflux release diagram](./docs/assets/konflux-serverless-operator-architecture-release.png)

## Apply Konflux configurations

1. Follow the instructions to access the Konflux instance
Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.