Skip to content

Commit

Permalink
Fix missing internal links in backing_services.md
Browse files Browse the repository at this point in the history
Change-Id: Ia91e79453c9f67decad1101cfa4a71c193dbc653
  • Loading branch information
mhuin committed Oct 13, 2023
1 parent 0857d7f commit e8d47ab
Showing 1 changed file with 8 additions and 6 deletions.
14 changes: 8 additions & 6 deletions doc/deployment/backing_services.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,14 +4,14 @@ Here you will find information about the backing services used by Zuul and Nodep

## Table of Contents

1. Philosophy
1. MariaDB
1. ZooKeeper
1. [Philosophy](#philosophy)
1. [MariaDB](#mariadb)
1. [ZooKeeper](#zookeeper)

## Philosophy

The goal of SF-Operator is to provide a Zuul-based CI infrastructure on OpenShift with the least
friction possible. With that in mind, we decided to minimize the prerequisites to deployment, and
The goal of SF-Operator is to provide a Zuul-based CI infrastructure on OpenShift with as little
friction as possible. With that in mind, we decided to minimize the prerequisites to deployment, and
thus decided to integrate "barebones" deployments of the backing services required by Zuul and Nodepool.

The pros are:
Expand All @@ -24,7 +24,9 @@ The cons are:
* Lifecycle support for these backing services is minimal (deployment, updates) compared to what a
proper operator-backed deployment could offer (see for example [what the mariadb-operator can do](https://mariadb.org/mariadb-in-kubernetes-with-mariadb-operator/)).

In other words, for backing services deployed as statefulsets, it is always possible to modify the replicas amount directly in their manifests, but SF-Operator will not act upon it - for example increasing mariadb's replicas will not set up a primary node and replica nodes like a dedicated mariadb operator would. You will only end up with one node being used by Zuul, and the rest using up resources for nothing.
In other words, for backing services deployed as statefulsets, it is always possible to modify the replicas amount directly in their manifests, **but SF-Operator will not act upon it** - for example increasing mariadb's replicas will not set up a primary node and replica nodes like a dedicated mariadb operator would. You will only end up with one node being used by Zuul, and the rest using up resources for nothing.

Generally speaking, the backing services are best left untouched and managed by the SF Operator.

## MariaDB

Expand Down

0 comments on commit e8d47ab

Please sign in to comment.