Allow 0 restart delay#781
Merged
Merged
Conversation
Current coverage is 55.11%
@@ master #781 diff @@
==========================================
Files 82 81 -1
Lines 11893 11724 -169
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 6321 6461 +140
+ Misses 4720 4397 -323
- Partials 852 866 +14
|
Contributor
|
What's wrong with using a negative value to disable restart delay? I am not sure it is a good idea to introduce another level of objects. |
Collaborator
Author
|
@stevvooe: My main concern with doing this is that the client would have to explicitly translate user input of 0 to a negative value. If we forget to do this in some case, we'll get the wrong behavior. It's also counterintuitive to someone working with the API that specifying |
aaronlehmann
force-pushed
the
0-restartdelay
branch
from
eecf9da to
df79f4d
Compare
Collaborator
Author
|
New plan: let's use the I'll update the PR. |
aaronlehmann
force-pushed
the
0-restartdelay
branch
from
df79f4d to
a6668e4
Compare
Collaborator
Author
|
Updated PTAL |
aaronlehmann
force-pushed
the
0-restartdelay
branch
2 times, most recently
from
95fe98e to
d0e8a60
Compare
Collaborator
Author
There was a problem hiding this comment.
Fixed, thanks.
aaronlehmann
force-pushed
the
0-restartdelay
branch
from
d0e8a60 to
2bedd31
Compare
Contributor
|
LGTM |
This makes Restart.Delay and Restart.Window nullable by using the Duration message type. Then the client can omit these fields to use the default values. If 0 is explicitly specified, 0 is used, not the default. For consistency, switch all other time.Duration values in the protobufs to use the Duration message type. This also fixes an inconsistency introduced when the orchestrator was changed to apply a default restart delay rather than doing this purely client-side. The default wasn't being applied when handling tasks at orchestrator startup. Fixes #721 Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
aaronlehmann
force-pushed
the
0-restartdelay
branch
from
2bedd31 to
1387084
Compare
Member
|
LGTM |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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 makes Restart.Delay and Restart.Window nullable by using the
Duration message type. Then the client can omit these fields to use the
default values. If 0 is explicitly specified, 0 is used, not the
default.
For consistency, switch all other time.Duration values in the protobufs
to use the Duration message type.
This also fixes an inconsistency introduced when the orchestrator was
changed to apply a default restart delay rather than doing this purely
client-side. The default wasn't being applied when handling tasks at
orchestrator startup.
Fixes #721
cc @aluzzardi