Skip to content

SF operator configuration

Context and Problem Statement

How the sf-operator deployment configuration is managed. This includes:

  • operator' components such as Zuul, Gerrit, ...
  • component's configuration, such as Zuul connections, Zuul tenant's config, Gerrit settings, ...

In sf-config, configuration is spreaded over:

  • the arch.yaml file
  • the config.yaml file
  • the common-vars.yaml file
  • the config repository

Considered Options

  • The K8S SofwareFactory Custom Resources and the config repository
  • TBD

Decision Outcome

Chosen option: TBD

Pros and Cons of the Options

The K8S SofwareFactory Custom Resources and the config repository

The Software Factory operator brings a SoftwareFactory Custom Resources schema that define:

  • the architecture (which components to enable)
  • the components' configurations

We mean by components' configurations any configuration needed by a component that is rational in term of definition schema complexity and size.

Configuration that is automatically generated from the config repository might be applied to the deployment by updating the CR instance or by updating specific resources like a configMaps.

The SoftwareFactory Custom Resource is applied via kubectl to deploy an instance of the sf-operator. At deployment the applied resources defintion is dumped in the config repository.

The config git repository and its workflow is the entry point to change the configuration of a sf-operator deployment. The repository is hosted on a review capable code hosting service (like the included Gerrit component) and stores the deployment configuration.

For instance:

  • the dump of the sf-operator CR (as applied via kubectl)
  • the SF resources definition (projects, Gerrit repositories, ...)
  • the Zuul tenants as flat files (outside the SF resources)
  • the Gerrit replication definition
  • the Nodepool configuration
  • Any additional Zuul config (jobs, roles, ...)

The config's workflow is built based on Zuul jobs:

  • config-check: to validate a configuration change
  • config-update: to apply a configuration change

The config-update job is capable of acting on the current deployment to update:

  • the architecture
  • the components' configurations

Finally, regarding this option the pros/cons are:

  • Good, because we keep a workflow almost similar to sf-config
  • Good, because we catch the whole configuration in the config repository
  • Good, because configuration is less dispatched over multiple files
  • Neutral, because it could brings the capability to remove critical config/component
  • Bad, because not isofunctional with sf-config