You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is nice. A dynamic, as-databases-are-packed, self-balancing infrastructure. Awesome.
And, not what we need right now.
We need to keep it simple.
statically distribute databases
When it is time to deploy, we need to do the following:
Look at S3 to see what sqlite files exist
Decide where they should go (knapsack, etc.)
Write a config file for the s0/1/... hosts that tell them what to grab. Put them in S3 in a config bucket.
Deploy
balance gets all of the configs, because it has to balance everything.
I wonder... if the config bucket could be a way of... every service fetching its config at wakeup? They only need to know about the S3 bucket that way... 🤷 Anyway. Another time, another ticket.
We do it this way because we need to be able to run the algo locally, and determine how many serve hosts to run. We can't dynamically spin up servers in cf/cloud.gov, so we have to be able to predict that in advance.
Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order
Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works.
Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate.
The text was updated successfully, but these errors were encountered:
jadudm
changed the title
implement static serve/balance infrastructure
🪨 implement static serve/balance infrastructure
Nov 26, 2024
At a glance
In order to keep things simple
as an architect
I want fewer moving pieces.
Acceptance Criteria
We use DRY behavior-driven development wherever possible.
then...
Shepherd
Background
#38 is too complex.
It is nice. A dynamic, as-databases-are-packed, self-balancing infrastructure. Awesome.
And, not what we need right now.
We need to keep it simple.
statically distribute databases
When it is time to deploy, we need to do the following:
sqlite
files exists0/1/...
hosts that tell them what to grab. Put them in S3 in aconfig
bucket.balance
gets all of the configs, because it has to balance everything.I wonder... if the
config
bucket could be a way of... every service fetching its config at wakeup? They only need to know about the S3 bucket that way... 🤷 Anyway. Another time, another ticket.We do it this way because we need to be able to run the algo locally, and determine how many
serve
hosts to run. We can't dynamically spin up servers incf
/cloud.gov, so we have to be able to predict that in advance.Security Considerations
Required per CM-4.
None. The config files are within the boundary, and as secure as the executables themselves.
Process checklist
If there's UI...
The text was updated successfully, but these errors were encountered: