You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'd like to use an official Helm chart for homeservers running in Kubernetes environments.
Describe the solution you'd like
We are running our homeserver in Kubernetes. After doing some research for maintained Helm charts, we couldn't find anything official; now I'm happy to have found this repository, seeing that other Helm charts have been implemented in the past.
Describe alternatives you've considered
One of the actively maintained charts we've found is the one by remram44, which works for us for now.
Still, I'd much prefer to use an official Helm chart:
matrix-helm depends on a custom image build of element, because of missing architecture builds and bad practices (using uid 0 in a container). Not sure if this is still the case, but should be fixed as well when providing official Helm charts.
it would signal that both Synapse and Element do work in Kubernetes, and that it's a supported deployment method. Is it? / Is that the reason why there are no Helm charts yet?
I don't know for how long remram44 can keep their chart maintenance up (thanks @remram44!)
Additional context
I think, with Synapse being under the element-hq "roof" as well, that now might be a good time to improve on Kubernetes compatibility & UX/DX.
We'd be happy to help with & contribute to this - providing feedback or working on a PR for this (although it could take time, as we'd need to schedule it internally with no urgent priority, as we have a working solution for now).
This would be a bigger feature anyway - at least bigger than just writing Helm templates:
used images should be tested and fixed for Kubernetes (maybe even OpenShift, introducing even more image requirements)
Synapse "monolith mode" vs "worker mode"
scalability of components - which pods could get replicated?
different federation "modes" (.well-known, DNS SRV, ...)
...
If you're open to this - should this be split into two issues, or do you think it's a good idea to keep related discussions at a single place?
The text was updated successfully, but these errors were encountered:
Keep in mind element-server-suite already uses kubernetes, i believe it's deployed as an operator. ESS is Element's bread and butter, so they probably don't wish to directly compete with themselves :p
Is your feature request related to a problem? Please describe.
I'd like to use an official Helm chart for homeservers running in Kubernetes environments.
Describe the solution you'd like
We are running our homeserver in Kubernetes. After doing some research for maintained Helm charts, we couldn't find anything official; now I'm happy to have found this repository, seeing that other Helm charts have been implemented in the past.
Describe alternatives you've considered
One of the actively maintained charts we've found is the one by remram44, which works for us for now.
Still, I'd much prefer to use an official Helm chart:
matrix-helm
depends on a custom image build of element, because of missing architecture builds and bad practices (using uid0
in a container). Not sure if this is still the case, but should be fixed as well when providing official Helm charts.Additional context
I think, with Synapse being under the element-hq "roof" as well, that now might be a good time to improve on Kubernetes compatibility & UX/DX.
We'd be happy to help with & contribute to this - providing feedback or working on a PR for this (although it could take time, as we'd need to schedule it internally with no urgent priority, as we have a working solution for now).
This would be a bigger feature anyway - at least bigger than just writing Helm templates:
If you're open to this - should this be split into two issues, or do you think it's a good idea to keep related discussions at a single place?
The text was updated successfully, but these errors were encountered: