FWIW, I’ve recently implemented a configuration library for a work project. 
It’s file-based, but I’m also investigating different approaches on 
configuration management. Mainly on this areas:

   - Configuration as a service. 
   - Real-time configuration changes (w/ REST interface to hook UIs). 
   - Components lifecycle (some components needs to be restarted to take 
   advantage of certain configuration changes). I’m thinking about 
   stuartsierra/component and puppetlabs/trapperkeeper. 
   - Applicability of the approach to on-premise solutions (mainly keeping 
   the application and its configuration in sync). 

drcfg seems to be a good case study, considering that you are using it in 
production. I’d love to hear some details about the operations side of the 
story, how it intersects with components lifecycles, and your thoughts on 
using it for on-premise solutions. My current local solution uses a schema 
(versioned and packaged with the application) to validate the configuration 
to keep it in sync with the runnin app, sounds like I coud hook that into 
the validator.

Cheers,
Manuel

Il giorno martedì 20 maggio 2014 23:33:05 UTC+2, Thomas Steffes ha scritto:

Hey folks,
>
> At Room Key we're using Apache Zookeeper and a home-grown clojure library 
> called drcfg for real-time application configuration management. We're 
> debating open-sourcing drcfg and are trying to gauge community interest in 
> such a tool. 
>
> We think it's got great usage semantics, basically you just def an atom in 
> any namespace where you'd like a variable that can be changed in real-time 
> on a running system. When you define the atom, you can also provide 
> defaults to fall back to if zookeeper is unavailable, a validator to be run 
> on any value when a change is attempted (to prevent invalid configuration 
> data), as well as some meta-data about the variable.
>
> We've also got a web UI we use to change configuration data, but that 
> would likely be released separate of drcfg itself.
>
> If anyone's interested, could you reply to this post? I can provide more 
> information as well if need be.
>
>
> -Thomas Steffes @ Room Key
>
>
>
> ​

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to