This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Be more explicit and concise during automation run #1249
Merged
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
- say why an image was added for updating - add another safeguard against dubious updates -- check the image creation date is not zero - don't bother logging when nothing happens
@rade points out that this won't avoid the situation where the image that would otherwise be considered the latest gets shuffled to the end of the list through having a zero timestamp. |
rade
approved these changes
Jul 24, 2018
if err != nil { | ||
logger.Log("error", err) | ||
continue | ||
} |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
daemon/images.go
Outdated
logger.Log("warning", "untagged image in available images", "action", "skip") | ||
continue | ||
} | ||
if latest.CreatedAt.IsZero() { |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
Since we'd expect an image with a zero timestamp to be shuffled to the end of the list, we probably won't hit the safeguard just put in, which checks whether the latest image has a zero timestamp. Instead, while we're looking for the current image so we can log the comparison, also check if _any_ images have a zero timestamp, and skip that container if they do. Ideally we'd avoid having data with this problem in the first place, but let's have defence in depth.
@rade Now checks all the images for a zero timestamp, and skips if it finds one. Care to take a quick look again? |
rade
approved these changes
Jul 24, 2018
Thanks! 👾 |
rade
added a commit
that referenced
this pull request
Jul 24, 2018
We got that slightly wrong in #1249.
rade
added a commit
that referenced
this pull request
Jul 24, 2018
An error while fetching an image manifest would return a nil error (hence indicating success) with a unit value image.Info{} struct. That is bad news for the caller in Warmer.warm(), which will map an image tag to that empty image.Info{}, polluting the cache entry for the image+tag and image in memcached. When we subsequently use this info to determine the latest suitable tag, we encounter zero CreatedAt timestamps, which, prior to the changes in #1247, #1249 and #1250 would cause the wrong images to be released. Fixes #1127.
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.
creation date is not zero
Not intended to cl0se #1127, but may give us more information about what it think it's doing, if it does it again.