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
