# Configuration

We need to rethink how we handle component configs.

## Why

* The Kubernetes operator will be decoupled from Instana releases,
i.e. it will be possible to tell the operator what Instana version to deploy
Additionally, it will be possible to override individual component versions
* The ultimate goal is to run the operator in SaaS
* Team Enterprise wants a new test system based on the operator
* If we ever shift left, centralized configs are in the way

## Problem

Currently, the operator packages configs with the release.
This will no longer work if we decouple the operator from the Instana release cycle.

## Goals

* Each service has its own config in the classpath.
This should be a default config suitable for local development.
* The default config should be overridable with additional config files.
At runtime, the files should be merged with the additional config files
overriding the defaults in the specified order.
Spring has such a mechanism (`SPRING_CONFIG_ADDITIONAL_LOCATION`).
Something similar can be implemented for Dropwizard
(e.g. https://github.com/earlye/dropwizard-multi-config)
* Whenever new configs are added to the default config,
there should be no surprises, i.e. defaults must be reasonable
and should not break the application when it is updated.

## Transition

During a transition phase, we could package up the configs in a separate Docker image that's part of the regular release cycle.
The operator could pull in this image and get configs from it.

## Configs vs. Feature Toggles

DropWizard configs ideally should not contain feature toggles.
It should only contain technical configs for Dropwizard
and such configs that adapt a component so it can run in a specific environment (e.g. DB configs, etc.).
Feature toggles should be handled completely separately.
Once, this is the case, configs should be fairly stable anyways.
However, this is to be discussed separately.