Evaluate other config storage options about open-match HOT 5 CLOSED

It's a nice idea at first look:

• We'll have a single source of config in OM cluster and we'll be able to mount it at a any path into containers as a file.
• The container mount will receive auto updates when ConfigMap data is changed. There's a way to prevent it: using subPath feature.
• Also it's possible to split configuration into separate smaller specific files but have them deployed in the same ConfigMap still. And then mount specific parts of the ConfigMap at specific paths into conatiners. (Or pass them as env vars.)

Some questions arise however:

1. Feels like we'd better keep Redis username & password in a Secret. But at the moment that's not possible to inject the data of a Secret into the data of ConfigMap using only default k8s tools. So if we decide to store Redis credentials as a Secret we'll have to pass it to containers as env vars.

2. Other thing is the way how ConfigMaps are created and updated in k8s:

   • Start like this:
     kubectl create configmap om-configmap --from-file=config/matchmaker_config.json
   • Then every time you update the config file locally you'll have to do something like this to deploy the fresh version:
     kubectl create configmap om-configmap --from-file=config/matchmaker_config.json --dry-run -o yaml | kubectl replace configmap om-configmap -f -

Alternatively it's possible to do kubectl apply -f configmap.yaml both for creation and update but to achieve this we need to keep the config data inside the ConfigMap resource definition:

apiVersion: v1
kind: ConfigMap
metadata:
  name: om-configmap
data:
  matchmaker_config.json: |
    {
      "debug": false,
      ...
    }

Some tools like kustomize offer ways to keep config data separate from ConfigMap definition and still be able to kubectl apply -f ....
But then we end up managing config files for these tools...
Well, maybe kustomize will also help with substitution of credentials into configmap (not sure for now) though the credentials will become "declassified" then...

Answering some other your questions:

How does this impact running components outside of k8s (i.e. dev env on local machines?

Config maps work fine on minikube.

What happens if the config isn't there yet at startup?

The pods referring it won't start.

from open-match.

Yeah, in this case we might just go ahead and do Redis credentials as a secret that can be put into env vars directly by the pods. Right now all 'secret' values are optional anyway, so I'm okay having them in a separate resource.

I'll think more about the format of the ConfigMap and write back.

from open-match.

Yeah, I think that we'll deal with the kubectl replace command and just document it heavily. We should break out Redis credentials to a secret as mentioned. We'll also want to take this opportunity to move the config file from json to yaml so we can start adding comments; there are a lot of options in there and we need to start having them documented in the file. Part of that will be updating the config/config.go:ReadConfig() function to look for yaml as well.

from open-match.

Will be included in 0.4.0 targeted for release in late Feb 2019

from open-match.

The configs were removed from the docker images, there's a now a ConfigMap created that will mount config/matchmaker_config.yaml.

Changes that resolved this:
#104
#81

from open-match.