comment addressed. ptal.

THanks!
--brendan

LGTM

I suspect this broke the liveness test? Not sure - will know more later. See #3108

In general, what's to prevent an image from getting cleaned up after it's pulled but before it's started?

I don't think that my PR is the cause. Esp. because liveness.sh failed in
http://bburns-linux.sea.corp.google.com:8080/job/kubernetes/1025/, but e2e
for this PR wasn't run until
http://bburns-linux.sea.corp.google.com:8080/job/kubernetes/1026/ where
liveness worked.

The docs for dangling are here

https://docs.docker.com/reference/commandline/cli/ (search for "dangling")

They:

"This will display untagged images, that are the leaves of the images tree
(not intermediary layers). These images occur when a new build of an image
takes the repo:tag away from the image ID, leaving it untagged."

So unless the tag isn't placed until a long while after the pull completes,
it seems unlikely it could cause this.

I think I see the reason for the flake in liveness.sh, I think I pulled the
initial restarts number prior to the pod actually being fully up, so there
was no value to pull. I will catch and poll until I get a
number.

Will add this as a note on the issue you filed.

On Mon, Dec 22, 2014 at 6:21 PM, Daniel Smith notifications@github.com
wrote:

I suspect this broke the liveness test? Not sure - will know more later.
See #3108 #3108

In general, what's to prevent an image from getting cleaned up after it's
pulled but before it's started?

—
Reply to this email directly or view it on GitHub
#3097 (comment)
.