Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Possibility to use separate environment variables for options inside arrays #841

Open
FZambia opened this issue Jun 30, 2024 · 0 comments

Comments

@FZambia
Copy link
Member

FZambia commented Jun 30, 2024

Is your feature request related to a problem? Please describe.

Centrifugo now has several places in configuration where array of objects is used:

  • proxies
  • consumers

It's now hard to configure secrets of nested objects from environment. For consumers Centrifugo provides ways to redefine some secrets using env vars, but still it's a manually injected env vars.

Describe the solution you'd like.

Would be nice to come to the unified approach to configure array of objects and support re-defining all the options from environment variables. Without manually defining specific env vars. I.e. we should use reflection to find out env var for each option. Environment variables should use name property of object (it's already unique and required) to distinguish between configuration objects of the same type (like two different GRPC proxies, or two different PostgreSQL consumers).

I also would like to change the env var names used in consumers a bit - putting the name of consumer before the type. For example, CENTRIFUGO_CONSUMERS_KAFKA_MYCONSUMERNAME_BROKERS becomes CENTRIFUGO_CONSUMERS_MYCONSUMERNAME_KAFKA_BROKERS. This makes more sense to me to configure in this way, because the nesting is more obvious: centrifugo -> select consumers -> select specific consumer -> set specific consumer configuration option.

We also have a couple more arrays of objects in the configuration:

  • namespaces
  • rpc_namespaces

My current thinking is that we should not change them since there are no certs/secrets or nested objects inside. So passing them as JSON encoded string from environment does not seem a bad thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant