I wrote a ZooKeeper based config system at Climate Corporation. I also found that there is a need to trigger some action when a config value changes, and went with a simple callback solution. I do like the idea of tying this to Stuart's Component lifecycle model; although I think you would also need the callback option for legacy code.
Another feature that was important to us was overrides for development. When you start a system locally in dev mode, you probably don't want it to use the production (or even QA environment) config. So we allow overrides in a local file. A few other features that we support, and I would like to see in a generic open-source solution: - Callbacks for config changes as explained above - Caching of the most recent config, in case the system restarts and ZK is not available - Command line client for viewing and modifying config - History of changes to config - A notion of environment (we have multiple ZK clusters, and a 'promote' command in the CLI tool to migrate from one to another-- this could also be done with multiple branches in one ZK cluster) - Public profiles that can be optionally merged in. When an app starts, it specifies it's system name and that branch is pulled from the overall config in ZK, but there are also some values that are shared across apps. These shared configs can go in public profiles, and then the App specific which public profiles it wants to merge in. The app can always override a public profile value by specifying the same key in it's app-or-system-specific config. Some other features that I haven't implemented, but I would like: - Web client for config viewing and modification - Templates (for a group of config options that might be re-used) which can be copied and then edited - A standard way for an app to say (document) what config values it needs - Simple transactions, so multiple config changes can be made or promoted at once marc On Wed, May 21, 2014 at 5:57 AM, Manuel Paccagnella < manuel.paccagne...@gmail.com> wrote: > 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. > -- 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.
