This repository has been archived by the owner on Sep 9, 2020. It is now read-only.
Do not scale a job group when it is in deployment. #56
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
jrasell
added
area/scaling
When a job group is going through a Nomad deployment, it is preferable not to trigger a scaling action. This is because with a basic deployment in Nomad, performing a scaling register will cancel the currently running deployment. This can therefore cause un-expected results. In order to track deployments, a blocking query is used on the Nomad API. Updates are then processed and stored internally for quick lookup. This reduces the load on the Nomad API over calling it to check every job group when a scaling action is requested. It does add complexity. The deployment state is not written to the storage backend, nor is it leader protected. Nomad itself is the state store for this info and new servers can quickly and easily update their internal state to ensure consistent results. This reduces load on the store and means faster lookup times. Closes #44
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
When a job group is going through a Nomad deployment, it is
preferable not to trigger a scaling action. This is because with a
basic deployment in Nomad, performing a scaling register will
cancel the currently running deployment. This can therefore cause
un-expected results.
In order to track deployments, a blocking query is used on the
Nomad API. Updates are then processed and stored internally for
quick lookup. This reduces the load on the Nomad API over calling
it to check every job group when a scaling action is requested. It
does add complexity.
The deployment state is not written to the storage backend, nor is
it leader protected. Nomad itself is the state store for this info
and new servers can quickly and easily update their internal state
to ensure consistent results. This reduces load on the store and
means faster lookup times.
Closes #44