Skip to content

Use DB feature flags for the migration allow/deny lists

Context

Please see &6068 (closed) for additional context.

This is a followup from !582 (comment 562177079), which was the PoC for the dual-path request routing as proposed in #374 (closed).

Proposal

With the metadata database, we can have a features/feature_gates table (similar to Rails) to configure feature flags and read from there at runtime. The first use case for this would be the migration include/exclude features that are currently exposed as config parameters and require an app restart whenever updated.

Note: This and #395 (closed) are mutually exclusive. If the latter turns out to be inviable, we should implement this, although it's not a blocker for Phase 1 as the corresponding FFs are already implemented using configuration file parameters (but not as convenient or easy to update).

Conclusions

We decided to move one with the Rails side FFs for the rollout. The investigation was done in #395 (closed) and the implementation will be done in gitlab#335260 (closed).

Edited by João Pereira