GH-524 staging environment #532
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Split out docker setup for potentially used on other nodes. Putting custom vars into extra-vars file to be referenced on cli while executing script.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
hevans66
reviewed
Jul 20, 2023
|
|
||
| # slow_start = 60 | ||
|
|
||
| # TODO: need to figure out healthcheck for IPFS |
There was a problem hiding this comment.
Yeah, this is a rabbit hole I started down at some point.
hevans66
approved these changes
Jul 20, 2023
There was a problem hiding this comment.
This is looking great its certainly a more complete set up than we had before.
Coupe of notes:
- This does not set up a receptor instance for staging. I think that's ok for now, but I think as soon as the receptor starts doing fancier things (like actually rejecting jobs based on criteria) we will want to add a receptor for testing purposes.
- I'm a little worried about the requester instances having an auto scaling group. Mostly because I don't really know what it means for two bacalhau requester nodes (that are not peered together)
to share the same set of compute nodes. What would happen if one requester node accepts a job and hands it off to a compute node, then the cli later requests the job status and that request goes to a different requester node? The requester node is not doing any computation so I don't anticipate ever really needing more than one. Unless the idea is to never n > 1 for this asg. - This still won't automatically run the ansible provision scripts when an instance launches right? For now were still running ansible-playbook from command line?
| @@ -1,109 +1,67 @@ | |||
| - name: Provision Bacalhau Compute Instance | |||
| remote_user: ubuntu | |||
| hosts: tag_Type_compute_only:&tag_Env_prod | |||
There was a problem hiding this comment.
Are you limiting to specific Env's when running ansible-playbook? Or is there some magic I am missing.
There was a problem hiding this comment.
yeah using --limit tag_Env_staging while executing ansible-playbook command.
Yes recepter will definitely come later.
|
Against incorrect environment
There was a problem hiding this comment.
Looks good to me, but I'll defer to @hevans66 on the final approval. I do think the large upcoming strategic decision that is coming up is, how we organize the infrastructure code for the private versus public clusters.
| @@ -4,6 +4,12 @@ | |||
| vars: | |||
| ipfs_path: /opt/local/ipfs | |||
| tasks: | |||
| # Must provide limit flag to ensure running against current environment | |||
| - fail: | |||
There was a problem hiding this comment.
Cool, didn't know about this trick
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Split out docker setup for potentially used on other nodes.
Putting custom vars into extra-vars file to be referenced on cli
while executing script.
Fixes #524