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

Allow usage of environment variables in config file #40

Open
danpalmer opened this issue Feb 16, 2018 · 0 comments
Open

Allow usage of environment variables in config file #40

danpalmer opened this issue Feb 16, 2018 · 0 comments

Comments

@danpalmer
Copy link
Contributor

From #35...

@PeterJCLaw

I realise we already have some credentials in the routemaster config file (specifically webhook API keys end up there), though I wonder whether we should look at a way to separate the configuration of the routemaster instance itself from the specification of the state machine. I'm not sure where the boundary for that is (it's certainly fuzzy at the moment), though I wonder whether this is something that will be needed if we want to be able to deploy the credentials in an explicitly secure manner.

@danpalmer

Yep, we will need this, but I don't think we need it in this PR.

My thinking is that the configuration is relatively complex, and dynamic per plugin, and that it's nice to have config in one place (at least per plugin), so I think a mechanism to signal in the yaml to look for an environment variable instead might be the best option.

I realise this might sound a bit odd, but I've used a similar system in the past: https://github.com/yesodweb/yesod/wiki/Configuration

Something like:

plugin:
  logging:
    - class: routemaster_sentry.logger:SentryLogger
      kwargs:
        dsn: $ENV[SENTRY_DSN]

This keeps it simple for the basic use-case, and in the advanced use-case still keeps the core of the configuration in one place.

We should do this, or something similar.

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

No branches or pull requests

1 participant