Cleanup configurations and code for migration Redis::Sessions
Application side changes
-
update chef configuration to point sessionsto the ServiceRedisClusterSessions -
update k8s configuration to point sessionsto the ServiceRedisClusterSessions -
CRs to coordinate above MRs: -
remove MultiStore, multistore feature flags andClusterSessionshelper classes: gitlab-org/gitlab!181631 (merged) -
delete MultiStore feature flags via ChatOps once the MR above reaches production -
remove environment variable USE_REDIS_CACHE_STORE_AS_SESSION_STOREandGitlab::Sessions::RedisStoreimplementation:-
Rails MR: gitlab-org/gitlab!181637 (merged) (isn't blocked by CRs above nor MultiStore removal MR) -
gstg k8s workload MR: gitlab-com/gl-infra/k8s-workloads/gitlab-com!4169 (merged) -
gprd k8s workload MR: gitlab-com/gl-infra/k8s-workloads/gitlab-com!4170 (merged)
-
Config clean up
-
remove cluster_sessions,cluster_db_load_balancing, and any other danglingcluster_*configurations.-
gstg removal: -
gprd removal:
-
Removal of ServiceRedisSessions
-
removing runbook service gitlab-com/runbooks!8627 (merged) -
switch redis cluster's storage selector to sessions
-
-
removing VMs -
gstg: https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/merge_requests/10525 -
gprd: https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/merge_requests/10526 -
(We didn't do this but we should next time) Create silence for GCPScheduledSnapshotsDelayedto avoid paging EOC. See details below.
-
-
removing chef roles
Note on GCPScheduledSnapshotsDelayed alert
After the VM was removed, there was page for GCPScheduledSnapshotsDelayed alert (incident link). This alert triggers when a disk that should have scheduled snapshots (based on appearing in the snapshot logs in the past week) hasn’t had any snapshots in the last 6 hours. The alert was then silenced for 1 week, after which it would self-resolve.
Edited by Marco Gregorius