[services][feature-flags] Introduce AWS config
ClosedPublic
Actions

Authored by tomek on Feb 10 2023, 5:29 AM.

Details

Reviewers

Commits

Summary

Add new configuration for AWS and localstack. Versions of added libraries are the same as in backup service.
Depends on D6666

Test Plan

Write additional code to connect to dynamodb instance and check if it is possible to list all the tables both from remote and localstack instance.

Repository

rCOMM Comm

Branch

flags

Lint

No Lint Coverage

Unit

No Test Coverage

services/feature-flags/Cargo.toml
15	This isn't used by `backup` service. Here it is necessary because we would like to use `Uri` which in `backup` is provided by `tonic`.

tomek requested review of this revision.Feb 10 2023, 5:45 AM

varun added inline comments.

services/feature-flags/src/main.rs
24	do we need to assign a variable here?

This revision is now accepted and ready to land.Feb 10 2023, 8:43 AM

bartek added inline comments.

services/feature-flags/src/config.rs
27	Side note - we should prioritize the https://linear.app/comm/issue/ENG-2311/shared-rust-code-across-services for services - this is the third service where this exact function is copied.
services/feature-flags/src/main.rs
24	I suspect this is to avoid the `unused function/variable` warn, and this variable is going to be used in future diffs.

services/feature-flags/src/config.rs
27	Agree! I think we can discuss this during our next planning meeting.
services/feature-flags/src/main.rs
24	Yes, this gets used in next diffs

This revision was automatically updated to reflect the committed changes.

services/feature-flags/src/config.rs
27	Planning meeting are not the best venue for housekeeping tasks... they are closely tied to external goals we set, and "shared Rust code across services" is not easy to frame as an external goal What's blocking us from just creating a shared library right now and moving things over as we need them?

services/feature-flags/src/config.rs
27	What's blocking us from just creating a shared library right now and moving things over as we need them? I think our priority should be to deliver the goals. If we have some time at the end, we can work on additional things. Planning meeting are not the best venue for housekeeping tasks... they are closely tied to external goals we set, and "shared Rust code across services" is not easy to frame as an external goal Even when it is an internal goal, it still takes time and prioritizing this over an external goal should be a conscious decision. I'm not sure if limiting planning meetings to just external goals is always beneficial.

services/feature-flags/src/config.rs
27	I think our priority should be to deliver the goals. If we have some time at the end, we can work on additional things. Generally agree with this, but I also wonder what the cost is. Seems like it would be rather easy to just create a shared library and start using it. I feel like I've seen you request changes when somebody copy-pastes code from `native` to `web` to reach a monthly goal, for instance... I think this is a similar thing. If the cost is low enough, I think we can start sharing code by just introducing the library and starting to use it.