Hello,
In most cases, admins reconfigure Squid to change a small portion of
the configuration while the majority of squid.conf and Squid
functionality stays the same. Yet, Squid dutifully shuts almost
everything down, configures modules/features almost from scratch, and
then starts them up. This shutdown-configure-start behavior creates
user-visible disruptions, complicates code, increases the chance of
memory leaks, leads to memory overuse, may hurt caching, spoil
statistics, etc.
We cannot solve this problem immediately, but we can improve old
features as we go and minimize mistakes in the new code. I would like to
propose the following four design principles to guide us long-term as we
work on individual modules/features or add new ones:
P0: Reconfiguration is not meant and will never be able to replace a
full Squid shutdown and start. Some residual effects from the initial
configuration are likely to persist. Some Squid features/modules/parts
may never support reconfiguration. Some subtle/hidden relationships
between features may not be fully tracked during reconfiguration. Our
goal is to maximize the number of properly supported reconfiguration
changes while minimizing reconfiguration-caused problems/disruptions. It
is a complex balancing act.
P1: If its configuration has not changed, the feature/module does not
have to do anything in reaction to reconfigure. It may keep running and
functioning as it was. It does not have to shut down and restart. For
example, if configuration affecting all aspects of a listening port has
not changed at all, Squid does not have to stop listening and close the
corresponding socket (even if there are probably some use cases that
benefit from Squid doing so).
P2: Each feature/module has the right to determine what constitutes its
"configuration" in P1. Even though nearly every Squid feature may have
an indirect effect on other Squid features, we have to draw lines
somewhere (per P0). The important thing here is consistent, predictable
behavior, not 100% coverage graph of all possible inter-feature
dependencies.
P3. By default, if a feature/module claims that its configuration
consists of N direct and related squid.conf settings (S1 ... SN), then
the feature should consider its configuration unchanged if
* each Si value has not changed AND
* for each Si that the feature knows to be a name of a local file
containing additional configuration input (e.g., a file containing
an SSL certificate), the last modification timestamp of that file
has not changed.
P4. Any feature/module decision about its configuration changes can be
overwritten by an admin. In other words, the admin has the right to
force any feature to assume that its configuration has changed. How this
is done and whether this is done for all features at once or selectively
are separate questions not discussed here for the sake of focus.
Do we agree on the above?
Needless to say, the vast majority of current modules/features do not
follow the above principles today. That is OK. If we agree on these
principles, folks can start adjusting the existing features to meet them
and ensure that newly proposed features comply when feasible. Any
decision would be specific to the feature, of course, but having these
principles helps.
Furthermore, if we agree, we can add a simple, general API to implement
P3 (and P4) logic for any feature that wants to use it without forcing
other features to make changes. This will make it much easier to support
these principles.
Thank you,
Alex.
P.S. The proposed principles are mostly orthogonal (but can be added) to
the "hot reconfiguration" problems currently discussed at
http://wiki.squid-cache.org/Features/HotConf
