Follow-up from https://gitlab.com/gitlab-org/gitlab-ce/issues/30392 support for multiple key value stores - create key factories?
Background:
There are approximately 20 Redis key prefixes in use by gitlab at the time of this writing. From the key name itself, it is sometimes hard to tell the persistence and retention policies that should apply to the stored values.
What questions are you trying to answer?
Can creation of new keys be simplified in a meaningful way to allow a single source of truth for data retention and persistence policies?
Are you looking to verify an existing hypothesis or uncover new issues you should be exploring?
Uncovering new issues as well as addressing known ones.
What is the backstory of this project and how does it impact the approach?
issue was discussed at https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11573#note_31088526
after looking at this one, it seems better to me to leave the name with WHICH redis instance it is intended for. "redis_key" is too ambiguous and makes it harder to debug and write code down the line.
Perhaps it makes more sense long term to have this as "key factory" on the ::GitLab::Redis::SharedState" object ... guardrails to keep future programmers from tripping on themselves? Also, having all of the key prefixes in one place as a dictionary of some sort could aid in understanding the various keys found in a live redis instance.
Currently, there are 5 key prefixes manufactured this way:
app/models/project.rb
lib/gitlab/chat_name_token.rb
lib/gitlab/exclusive_lease.rb
lib/gitlab/lfs_token.rb
lib/gitlab/etag-caching/store.rb
- do any of the above belong in the more volatile "caches"?
- do any of the above belong in the pubsub/queues functionality?
What do you already know about the areas you are exploring?
The following discussion from !11573 (merged) should be addressed:
-
@rspeicher started a discussion: (+3 comments)
What does success look like at the end of the project?
Easy to understand generation of new keys in a manner that promotes on boarding, consolidated policies for data retention and persistence, single source of truth for key prefixes.