Agreed 2# is the better way to go in the future of keeping configs & stats with the modules, plugins, etc.
-George On 9/20/10 3:41 PM, John Plevyak wrote: > > > After a bunch of thought and discussion I think #2 is the way to go: > > - localizing configs to modules decreases cross module dependencies > - removing the duplicates reduces confusion and the deceptiveness > of the current overridden defaults > - it is a relatively small change which is good at this time > > kpjm > > On 9/20/2010 2:30 PM, Leif Hedstrom wrote: >> Hi all, >> >> I'm going back and forth on this issue, and I can't make my mind up. A >> very large majority of configurations are currently registered with the >> librecords system using proxy/mgmt2/RecordsConfig.cc. About ~100 or so >> configurations are also registered in various iocore files, and most of >> them are duplicates. Such duplicate registrations ends up being a >> "no-op", and has no effect (other than being confusing, particularly >> when the default differs from RecordsConfig.cc). >> >> Here's the thing, this was (apparently?) a partially completed effort to >> modularize the configuration registrations into various "modules". I can >> definitely see the benefits of doing this (although I'd like to see a >> more standardizes registration systems across modules), which is why I'm >> coming here to ask for a discussion of what we should do. Here are some >> ideas: >> >> 1) Do nothing, and just leave the iocore ones as they are. I.e. keep the >> confusion as is :). >> >> 2) Remove the duplicates from proxy/mgmt2/RecordsConfig.cc, and update >> the defaults in the iocore code accordingly where they differ (we should >> stick to the defaults from the current RecordsConfig.cc, since that's >> what takes effect). >> >> 3) Remove the duplicates from the iocore modules, and leave the configs >> in proxy/mgmt2/RecordsConfig.cc >> >> >> Going forward (v2.4 or later), we should also take into considerations >> that we'll want to support per remap rule configurations for many of >> these settings (think VirtualHost in Apache HTTPD), which would (again) >> require major code changes. Or perhaps even more realistically, properly >> support hierarchies of configurations, where we find the most specific >> configuration first. >> >> So, a goal for v2.2.0 could be to at least clear up where there is >> confusion and ambiguity (e.e. ~100 or so duplicated configuration >> registrations, many of which have different default values). But at the >> same time, not waste time on something that we'll redo later anyway. >> >> Thoughts and comments? >> >> -- leif >
