sftd: add support for multiple SFT servers #1325
Conversation
| @@ -1,5 +1,8 @@ | |||
| # SFTD Chart | |||
|
|
|||
| In theory the `sftd` chart can be installed on its own, but it's usually | |||
| installed as part of the `wire-server` umbrella chart. | |||
There was a problem hiding this comment.
Just a thought: I understand it might be nice to just say "helm install wire-server", though often "more complex" services (stateful ones or those with slower update cycles like SFT due to e.g. not wanting to cut ongoing calls out for 6 hours or so) being bundled into an otherwise fast-to-upgrade chart may slow any wire-server upgrades down going forward. I presume some scripts and/or helmfiles to be in use anyway, as more than a single chart needs to be installed.
Not sure if there are benefits otherwise that I might be missing? Or do I overestimate potential downsides?
(feel free to go ahead with the wrapper chart approach, just wondering about the motivations)
There was a problem hiding this comment.
I'm really on the fence between the two options. It was originally the way you just described and I only changed it today...
Motivation was:
I wanted to do a bit of refactoring in the wire-server umbrella chart in a follow-up PR so that there is a globals.baseDomain option that all charts can use to remove all the domain duplication in our values.yml. As a form of experiment I wanted to make the SFT chart (which needs to know the base domain; and the domain name of the webapp chart) use this method of configuration to set its host and allowOrigin options.
Also helm upgrade --wait only waits for new pods to be spawned; it doesn't wait for old pods to be terminated; so even with a slow update cycle (due to setting terminationGracePeriodSeconds to a few hours) upgrades would still be "snappy".
However now I just realised that's only true for Deployment; not for StatefulSet; as StatefulSet replaces pods one by one (See Future Work section at the bottom of the README) so it might take longer for --wait to return.
I'm going to sleep on it and revisit tomorrow. I might end up reverting this again.
There was a problem hiding this comment.
I was inspired to structure stuff a bit like:
https://gitlab.com/gitlab-org/charts/gitlab
https://docs.gitlab.com/charts/charts/globals.html#configure-host-settings
There was a problem hiding this comment.
@jschaul I have made it clear in the docs that both ways are possible. docs.wire.com currently still instructs to not use the umbrella chart
There was a problem hiding this comment.
@jschaul I have made it clear in the docs that both ways are possible. docs.wire.com currently still instructs to not use the umbrella chart
Great! Thanks!
* The ingress assigns an SFT allocation request to a random SFT * Each sftd pod is made aware of an URL on which it is directly reachable, and will return the URL in the response to the client. e.g. Pod `sftd-0` will be assigned `https://sft.example.com/sfts/sftd-0` * The client tells this URL to other clients willing to join the call * Other clients make a request to this URL * The ingress points requests to `/sfts` to the `join-call` deployment, which will redirect to the specific pod, such that the client can join the conference call of the other client
some kubernetes clusters (like Scaleway) don't name the DNS server kube-dns but core-dns. /etc/resolv.conf is guaranteed to point to the correct thing though.
This makes it quicker to scale up and down. As sft is actually not stateful and does not require ordered restarts. We're just using StatefulSet to get a persistent DNS name so we can join existing calls.
Co-authored-by: Lucendio <gregor.jahn@wire.com>
We can make deployment of sftd a bit easier in the future. Added a section on this so I do not forget :)
Also make the docs a lot nicer.
reachable, and will return the URL in the response to the client. e.g.
Pod
sftd-0will be assignedhttps://sft.example.com/sfts/sftd-0/sftsto thejoin-calldeployment,which will redirect to the specific pod, such that the client can join
the conference call of the other client