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
The idea for this is inspired by charts I've used for database deployments - usually the credentials for the database can be generated for you during the deploy and stored in a Secret.
The nice part about this behavior is you don't have to worry about manually setting up the secret for your API server also running in the cluster; you can set up the API server deployment to reference the secret generated by the Livekit release by name with an expectation that it will be present and kept in sync even if Livekit is redeployed.
The only wrinkle might be if the format or generation of the keys is particular in some way such that it can't be generated on-the-fly during the templating (like how Neo4J does it). A cursory look at the server codebase seems to indicate it's just random strings though, so this might work?
The text was updated successfully, but these errors were encountered:
Would also say, this applies to the redis part. For example, I don't want my redis password in git
Which means, the values file can't be in git
Which means, I can't use argocd to deploy this - not something that I want to do (or not do)
The idea for this is inspired by charts I've used for database deployments - usually the credentials for the database can be generated for you during the deploy and stored in a Secret.
The nice part about this behavior is you don't have to worry about manually setting up the secret for your API server also running in the cluster; you can set up the API server deployment to reference the secret generated by the Livekit release by name with an expectation that it will be present and kept in sync even if Livekit is redeployed.
The only wrinkle might be if the format or generation of the keys is particular in some way such that it can't be generated on-the-fly during the templating (like how Neo4J does it). A cursory look at the server codebase seems to indicate it's just random strings though, so this might work?
The text was updated successfully, but these errors were encountered: