move some of plan.go into a proper FSM #3875
Draft
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
this doesn't involve too many code changes, more just shifting code around. the reason for doing this is that, if we can move as many partso f deploys as possible into an FSM, it lets us more easily resume deploys that failed, or from midway through a canceled deploy, or anywhere else in a deploy. I want to make more granular FSM transitions for each individual machine too, which I'll either do in a future commit or a future PR. The more individual FSM states we can retry, the more granular 'resuming' we can do. If we can move other parts of deploys into an FSM, it also gives us the ability to resume *those* parts as well. Plus some extra super powers like easily cloning apps, more granular view of deploy failures in a way that we can retry locally, declaratively configuring a fly app, etc.
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.
this doesn't involve too many code changes, more just shifting code around. the reason for doing this is that, if we can move as many partso f deploys as possible into an FSM, it lets us more easily resume deploys that failed, or from midway through a canceled deploy, or anywhere else in a deploy.
I want to make more granular FSM transitions for each individual machine too, which I'll either do in a future commit or a future PR. The more individual FSM states we can retry, the more granular 'resuming' we can do. If we can move other parts of deploys into an FSM, it also gives us the ability to resume those parts as well. Plus some extra super powers like easily cloning apps, more granular view of deploy failures in a way that we can retry locally, declaratively configuring a fly app, etc.
Change Summary
What and Why:
How:
Related to:
Documentation