Fixes after introducing the redis.yml unified config file
What does this MR do and why?
Two fixes needed after !106854 (merged) introduced the new redis.yml unified config file, which affected our previous behavior/expectations in a couple of subtle ways (heads up, there's some repetition bellow because it's copy-pasted from the commit messages):
Ensure resque.yml is the lowest priority redis config
In !106854 (merged) we added a unified redis.yml config file. When selecting a config file to use we intended the following precedence:
- redis.yml
- The value returned by
config_file_name - redis.yml for the fallback store
Since config_file_name returned resque.yml as a last resort, by
adding step 3. we broke a previous assumption that resque.yml would
always be the configuration file with the least precedence. This is
problematic because that file may be bogus in some installations, as per
33d2c0b6.
It also meant that redis.yml was ignored in some cases: for example
for ClusterRateLimiting, its fallback store is Cache. If there was
no cluster_rate_limiting key in redis.yml but there was one for
cache, it would still grab its values from resque.yml. This
patch makes it so that in this example the cache values in redis.yml
are used instead, and only if those also don't exist is resque.yml
used.
Make redis specs work with redis.yml
After !106854 (merged), a
config/redis.yml file may exist and specify certain values for the
test environment, taking precedence over other config files. Our specs
expect to be able to override configuration via instance-specific config
files. To keep that expectation valid, we make those specs work with a
different rails_root so the behavior is stable regardless of the
presence or absence of redis.yml.
Found these while preparing the codebase for the new DbLoadBalancer instance, which is intended to be the first deployed in production using the new redis.yml file.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.