Cache namespace first Auto DevOps config
What does this MR do and why?
Related to #330140 (closed)
Resolves an N+1 by caching lookup of first_auto_devops_config
for 1 day for each group. This configuration is unlikely to change often and is an expensive lookup so it makes sense to cache it.
The cache is proactively expired if any group ancestor of a given group changes the auto_devops_enabled
configuration.
Of note, as currently written, this change will store the cache for all namespaces on the same Redis instance/shard. It's required that the cache for a given hierarchy be on the same instance so we can efficiently expire the cache. However, it would be expensive to get the root_ancestor
to group the cache based on that.
In review we will explore whether this is acceptable and what other more efficient options are available.
Feature flag
Rollout issue: #353503 (closed)
This MR includes the feature flag namespaces_cache_first_auto_devops_config
, which is disabled by default. The flag is included out of an abundance of caution, because we know we have large customers that rely on this endpoint, and because the change is in a high risk area (Namespace model).
What is something goes wrong?
No data loss should occur. At worst, the API will return the wrong information, or perhaps AutoDevops will run or not run if the cache is incorrect. However the risk is not large.
Screenshots or screen recordings
These are strongly recommended to assist reviewers and reduce the time to merge your change.
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.