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.
