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
Right now, I think if you apply changes that only affect a bridge, OR need to restart a bridge using kubectl rollout restart deployment matrix-bridge-twitter for example.... it'll generate new config I think.... and the shared secrets wont be the same in the live version of synapse.
I think!
If the config exists, you shouldnt just go remake it? But then how do you deal with the issue of wanting to update the other config?
The text was updated successfully, but these errors were encountered:
Yeah, I've been having this same problem. I've been gradually tweaking the configuration of the bridge, but even if I make changes in values.yaml and upgrade the whole chart, if the bridges start after synapse, I have to restart synapse in order to restore communication.
I've been trying to think of a way to avoid regenerating the registration.yaml because helm re-runs helpers.tpl every time and makes new secrets. Would it be enough to just not copy in the initcontainer, it if it already exists, or would we have to copy it in the opposite direction?
Right now, I think if you apply changes that only affect a bridge, OR need to restart a bridge using
kubectl rollout restart deployment matrix-bridge-twitter
for example.... it'll generate new config I think.... and the shared secrets wont be the same in the live version of synapse.I think!
If the config exists, you shouldnt just go remake it? But then how do you deal with the issue of wanting to update the other config?
The text was updated successfully, but these errors were encountered: