-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(deploy): allow the container to raise in MIGs #6893
Conversation
These further changes could be optional. For testing, it's enough to just run a scheduled full sync in our test environment. To support the network, using a cached state will be better because the instances are live faster. |
This no longer requires the env variable to be defined in other places, unless we're changing the default configuration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving; interesting if mode=rw matters, docs say it is the default when unspecified for both --create-disk
and --container-mount-disk
* fix(deploy): allow the container to raise in MIGs * fix(docker): add the `ZEBRA_CACHED_STATE_DIR` as a default `ENV` This no longer requires the env variable to be defined in other places, unless we're changing the default configuration
Motivation
The Managed Instance Groups in GCP were not raising the container as those were expecting the device name and the correct RW/RO mode to match between the created disk and the disk we're mounting in the container.
This also fixes monitoring, and uses the same caching directory as in CI, as the Container Optimized Image does not allow mounting in non-standard linux paths for security reasons.
Fixes: #5644
Fixes: #6861
Specifications
See: https://cloud.google.com/sdk/gcloud/reference/compute/instance-templates/create-with-container#--container-mount-disk
Solution
--boot-disk-size 300GB
to the MIGs template, just as we have on CI and Single instance deploystdin
andtty
to standardize with other approachesZEBRA_CACHED_STATE_DIR
with/var/cache/zebrad-cache
as we do on CI, as thecos-cloud
doesn't behave correctly with non-standard paths.Review
Anyone from DevOps
Reviewer Checklist
Follow Up Work
We should make further changes in a following PR:
For releases, it should sync from scratch (1). Currently it's 2-4 weeks between releases, so a 3 day mainnet sync is ok.
For
main
branch pushes, it should have a cached state (2 or 3, whatever is easier or more reliable). We merge new PRs multiple times a day, so a cached state is needed.