Turn Server

[nikhiljha]

closes #10

Still WIP, I need to figure out the following...

• [x] How do we do multiple dockerfiles in one OCF repository? Or do we just pull the upstream image directly?
• [ ] How do we do secret management?
• [ ] What is the external IP for coturn, is it needed? The synapse docs say only the internal IP matters, but the Dockerfile I'm looking at says the internal IP doesn't matter if the external IP isn't set?
• [x] Should everything be namespaced to matrix? I don't even know what that does, but it sounds like a good idea to put matrix and coturn in the same namespace.
• [x] Mount an external config or keep the internal config like it has now? The config isn't that complex so I think it's fine as is.

BTW: Most of it was taken from here https://github.com/ananace/matrix-synapse/tree/master/kubernetes - which has updated almost immediately after each new matrix/riot update for a while now. Seems pretty reliable to me.

[cg505]

• [ ] How do we do multiple dockerfiles in one OCF repository? Or do we just pull the upstream image directly?

This is already being worked on this repo in #7, look how it's done there. Alternatively, look at ocfweb for a more stable repo that uses multiple Dockerfiles/images.

• [ ] How do we do secret management?

We need docs for this... but basically this is changing pretty frequently. Currently, there are two paths: hostPath mounts (example), or templated secrets injected during CI (example).

Also, ocf/utils#146 is on the horizon which will allow for easier usage of templated injected secrets.

All the secrets themselves are stored in the puppet private share on lightning.

• [ ] Should everything be namespaced to matrix? I don't even know what that does, but it sounds like a good idea to put matrix and coturn in the same namespace.

idk if they need to be in the same namespace. ocf-kubernetes-deploy will deploy to the app-matrix namespace, so you don't need to specify the namespace. If it should be in another namespace, it should be in a different repo.

• [ ] Mount an external config or keep the internal config like it has now? The config isn't that complex so I think it's fine as is.

imo build it into the dockerfile. We want to put config in git as much as possible, we should definitely avoid mounting it from some external FS or something when possible. So, from best to worst: build into Docker image > mount via ConfigMap or Secret > mount via external FS

[dkess]

If it's too hard to figure out how to get UDP into the cluster, you could opt to not use Kubernetes for this and instead make a VM.