Page MenuHomePhabricator

[services][feature-flags] Describe feature flags table in terraform
ClosedPublic

Authored by tomek on Feb 23 2023, 6:55 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 26, 10:17 PM
Unknown Object (File)
Sat, Oct 26, 10:17 PM
Unknown Object (File)
Sat, Oct 26, 10:17 PM
Unknown Object (File)
Sat, Oct 26, 10:12 PM
Unknown Object (File)
Sat, Oct 19, 12:44 PM
Unknown Object (File)
Fri, Oct 18, 5:13 AM
Unknown Object (File)
Fri, Oct 18, 5:13 AM
Unknown Object (File)
Fri, Oct 18, 5:12 AM
Subscribers

Details

Summary

Add terraform description of the tables with feature flags configuration.

Depends on D6852

Test Plan

Tested if tables were successfully created on localstack. I'll also need to test it on AWS, but I haven't done that yet.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

tomek requested review of this revision.Feb 23 2023, 7:31 AM
bartek added inline comments.
services/terraform/dynamodb.tf
218 ↗(On Diff #23002)

What's the motivation for using PAY_PER_REQUEST instead of PROVISIONED?
For other tables, we use provisioned mode and specify read/write capacity.

For localstack it doesn't matter anyway but I'm asking in context of AWS deployment.

This revision is now accepted and ready to land.Feb 24 2023, 1:24 AM
services/terraform/dynamodb.tf
218 ↗(On Diff #23002)

Feature flags table will be a lot smaller than other tables, writing to it will be performed rarely and only manually (after new release or when we decide to switch a flag). That means that we expect one write per couple of days which makes even the lowest provisioned capacity a couple of orders of magnitude too high for our needs.

Initially, reading is similar: one read per native app start, so at most a couple of reads per hour. In the future, if we decide to change an approach so that we query more frequently, we can change the policy.