Use viper for configs

[tsheasha]

The advantage of this is it gives us for free a lot of config type conversions, also a very advantageous feature,
is being able to watch the config and dynamically update the current config without restarting the service

[sarguru]

👍

[bobtfish]

Nice! (I don't have time to look at this till the weekend, but I'll look in
detail ASAP)
On 26 Feb 2016 12:20, "Sarguru Nathan" [email protected] wrote:

[image: 👍]

—
Reply to this email directly or view it on GitHub
#10 (comment).

[tsheasha]

I have not pushed any code through yet, I will start hacking on this over the weekend (hopefully)

[bobtfish]

Oh, cool, sorry - was misreading issue for PR! Do it! :)
On 26 Feb 2016 14:00, "T Sheasha" [email protected] wrote:

I have not pushed any code through yet, I will start hacking on this over
the weekend (hopefully)

—
Reply to this email directly or view it on GitHub
#10 (comment).

[bobtfish]

https://github.com/spf13/viper

[bobtfish]

Just checking in, I think I've got the integration tests working again (I'd screwed up the cloud-init stuff when upgrading go / switching to gom - the code was fine!), so I'm planning to kick the tires on this over the next few days.

[tsheasha]

I also did some more digging into viper, and I believe what we are using it for is an overkill since it is much more than a config watcher. However, given it's rather large supporting functions to convert data types and also the fact that you dont have to pass am object around explocitly ( due to it's singleton default behaviour) I believe using viper will simplify lots of the config related code.

If I have any more thoughts I will dump them here.