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
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
Currently, we use Terminating to represent both soft and hard terminating. If a backend is hard-terminated while it is being soft-terminated (which is allowed), a backend goes from a Terminating state to another Terminating state. This is the only allowed state transition that does not move forward in the state sequence.
The change in this PR is to split soft- and hard- Terminating states into their own separate states. Soft-termination keeps the name Terminating, and hard termination gets HardTerminating. The field termination in Terminating remains, but is deprecated, and can only be set to Soft in the constructor.
One thought: there will be a small window of time during a deploy where it'll be possible for p2 to receive unparseable BackendState update messages. That's only for messages that have a HardTerminating BackendStatus, though, which I'm guessing are rare. If we really wanted to avoid this, we could put the type changes in their own commit that comes first in the PR, then update plane version to that specific commit, deploy, then update to the latest commit and deploy again. It's kind of a hassle though, and might not really be worth it.
One thought: there will be a small window of time during a deploy where it'll be possible for p2 to receive unparseable BackendState update messages. That's only for messages that have a HardTerminating BackendStatus, though, which I'm guessing are rare. If we really wanted to avoid this, we could put the type changes in their own commit that comes first in the PR, then update plane version to that specific commit, deploy, then update to the latest commit and deploy again. It's kind of a hassle though, and might not really be worth it.
Terminating statuses are only created on the drone, so as long as we deploy the controller before the drones we should be fine.
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.
paulgb
force-pushed
the
paul/dis-2315-implement-hardterminating-status-in-plane
branch
from
Currently, we use
Terminatingto represent both soft and hard terminating. If a backend is hard-terminated while it is being soft-terminated (which is allowed), a backend goes from aTerminatingstate to anotherTerminatingstate. This is the only allowed state transition that does not move forward in the state sequence.The change in this PR is to split soft- and hard-
Terminatingstates into their own separate states. Soft-termination keeps the nameTerminating, and hard termination getsHardTerminating. The fieldterminationinTerminatingremains, but is deprecated, and can only be set toSoftin the constructor.