Dependencies

[prologic]

Why does this depend on so many heavy weight things? Etcd, Postgres? Can we lighten the dependencies at all?

[RichardKnop]

@prologic Yes this is an issue. Originally this project was coded against a specific stack I was working with and I haven't had time to simplify it and make it more generic.

I definitely agree it should be simplified so it can be plugged into other stacks but I haven't had time for that yet.

I think the etcd and postgres dependencies are not too tightly coupled. ORM was used so I think something like MySQL should probably work with only couple small changes. The etcd dependency could be removed altogether as config is just a struct, so it can be loaded in any other way (probably most sensible to load it from environment variables, perhaps from file).

I don't have enough bandwidth to work on this though so it would probably have to be done by somebody else.

[prologic]

What Is etcd used for here?

On Thu, Aug 3, 2017 at 02:24 Richard Knop ***@***.***> wrote: @prologic <https://github.com/prologic> Yes this is an issue. Originally this project was coded against a specific stack I was working with and I haven't had time to simplify it and make it more generic. I definitely agree it should be simplified so it can be plugged into other stacks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABOv-tkLror5-bitDDDVoH4JXx7faXblks5sUZG0gaJpZM4Or_Lb> .

-- James Mills / prologic E: [email protected] W: prologic.shortcircuit.net.au

[RichardKnop]

It stores a JSON (with stuff like database connection details, API keys, secrets, oauth2 configuration, session configuration) which is unmarshaled into config structure when you start the application. The running application then keeps live reloading the configuration from etcd.

When I started working on this project I was deploying to a CoreOS cluster which had etcd running on it. So it was a logical place to store configuration in as it's distributed so you load it once and all nodes in the cluster can access it.

It also simplified deployment of this app as docker container via cloud init files as you only needed to set a single environment variable to point the container to etcd.

[prologic]

Doesn't work very well in a non CoreOS env 😀 We should definitely refactor this part at least

On Thu, Aug 3, 2017 at 09:10 Richard Knop ***@***.***> wrote: It stores a JSON which is unmarshaled into config structure when you start the application. The running application then keeps live reloading the configuration from etcd. When I started working on this project I was deploying to a CoreOS cluster which had etcd running on it. So it was a logical place to store configuration in as it's distributed so you load it once and all nodes in the cluster can access it. It also simplified deployment of this app as docker container via cloud init files as you only needed to set a single environment variable to point the container to etcd. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABOv-jWMrUnwipam94seqrBAc-KFqpOTks5sUfD3gaJpZM4Or_Lb> .

-- James Mills / prologic E: [email protected] W: prologic.shortcircuit.net.au

[RichardKnop]

Yes I agree. Probably environment variables would be the best. Or we could support multiple ways of loading the configuration based on a command line flag (so from environment variables by default, but could be loaded from Yaml file if you pass a flag with filepath).

[prologic]

The later sounds good! I hear Docker is also growing distributed config management soon too much like secrets

On Thu, Aug 3, 2017 at 09:15 Richard Knop ***@***.***> wrote: Yes I agree. Probably environment variables would be the best. Or we could support multiple ways of loading the configuration based on a command line flag (so from environment variables by default, but could be loaded from Yaml file if you pass a flag with filepath). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABOv-jCmtD0j-78XGjfsZn8v-7xWCmN9ks5sUfIUgaJpZM4Or_Lb> .

-- James Mills / prologic E: [email protected] W: prologic.shortcircuit.net.au

[tommyo]

Are you against the idea of using viper for config? It supports environment variables, yaml/json configuration files, command line arguments, etcd, and any mixture of all of them.

If you're ok with that, I'm willing to put some time into it. Would make it much easier to run in kubernetes.

[RichardKnop]

@tommyo I am all for it actually. I would do it myself but am really busy with day job and some other projects. Either viper or perhaps just something simple like github.com/kelseyhightower/envconfig would be preferable to the current etc requirement. Etcd live config could be kept as optional feature but default behaviour should be to try to load configuration from environment variables or file system.