Measurement of namespace storage statistics
This is a follow up of https://gitlab.com/gitlab-org/gitlab-ce/issues/62214
After https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28996 gets deployed to GitLab.com, we need to measure the performance in different environments: staging and production.
### Prework
There's some prework that needs to be done and deployed before starting the measuring:
* [x] Fix [Namespace::AggregationSchedule should keep the lease until timeout](https://gitlab.com/gitlab-org/gitlab-ce/issues/64079) - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30305
* [x] Include [edge case](https://gitlab.com/gitlab-org/gitlab-ce/issues/62214#note_187584895) to refresh root statistics on other scenarios - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30329
### On staging
* [x] Once is one staging, enable the Feature Flag globally and observe.
```
/chatops run feature set update_statistics_namespace true --staging
```
* [x] If there aren't any degradation problems, tune down the time to `1.5h` (half of the default):
* We'll need access to the rails console on staging, or someone that runs the commands for us:
```ruby
# To set the timeout to 1.5
Gitlab::Redis::SharedState.with do |redis|
redis.set(Namespace::AggregationSchedule::REDIS_SHARED_KEY, 1.5.hours)
end
```
```ruby
# To check the delay timeout
=> Namespace::AggregationSchedule.delay_timeout
=> 5400
```
### On production
If there aren't any major problems on staging:
* [x] We enable the Feature Flag for `gitlab-org` for `1h` and observe
```
/chatops run feature set --group=gitlab-org update_statistics_namespace true
```
* [x] If there aren't any degradation problems, we enable the Feature Flag for `gitlab-org` for `1 day` and observe.
* [x] If there aren't any degradation problems, we enable the Feature flag for `gitlab-org` for `3 days` and we observe
* [x] If there aren't any degradation problems, we enable the feature flag globally for 1 day and observe.
* [x] If there aren't any degradation problems, tune down the time to `1.5h` (half of the default) and observe.
```ruby
# To set the timeout to 1.5
Gitlab::Redis::SharedState.with do |redis|
redis.set(Namespace::AggregationSchedule::REDIS_SHARED_KEY, 1.5.hours)
end
```
```ruby
# To check the delay timeout
=> Namespace::AggregationSchedule.delay_timeout
=> 5400
```
* [x] If `1.5h` works, hardcode this value on the codebase probably. - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31341
- If not, hardcode the default value (`3h`)
- This has to be done on `Namespace::AggregationSchedule.delay_timeout`.
* [x] If there aren't any major problems on production, remove the feature flag.
* Hopefully we can include this change under %12.2.
* According to the [documentation](https://docs.gitlab.com/ee/development/feature_flags/process.html#including-a-feature-behind-feature-flag-in-the-final-release), we have to remove FF at least two working days before.
### Other commands
To disable the feature flag at any moment:
```
# On production for gitlab-org
/chatops run feature set --group=gitlab-org update_statistics_namespace false
# Globally on production
/chatops run feature set update_statistics_namespace false
# Globally on staging
/chatops run feature set update_statistics_namespace false
```
To restore 3h as the default time
```ruby
Gitlab::Redis::SharedState.with do |redis|
redis.del(Namespace::AggregationSchedule::REDIS_SHARED_KEY)
end
```
### Conclusions
* Performance on staging and production has been shown stable
* The introduction of these two models allows us to gather namespace statistics easily
* `1.5` as a lease window is enough for now. We can reduce the window in an upcoming iteration
issue