-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
weird: 'podman history' loses history if centos image is present #3359
Comments
The two images in question, centos and fedora, don't share any layers... I'm not sure exactly what could be going on here |
Fun addition:
(it's fixed!) |
Oops - one confounding factor: it's not just centos. It's the combination of centos and rhel:
Only when both are present does the history command show |
@mtrmac Any ideas here? |
Lots of heuristics in libpod/image… One thing that quickly jumps at me is (FWIW: the recorded history does not actually store image IDs; there is a record of the commands, and there is a sequence of layers. So, the history never records e.g. the |
@edsantiago @mtrmac What should we do with this issue? |
Issue still present in 1.5.0. What should we do? I don't know. I don't especially like it; I think |
This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days. |
Here we are nearly three months later and in the same state... |
@vrothberg PTAL |
Rewrite the backend for displaying the history of an image to simplify the code and be closer to docker's behaviour. Instead of driving index-based heuristics, create a reverse mapping from top-layers to the corresponding image IDs and lookup the layers on-demand. Also use the uncompressed layer size to be closer to Docker's behaviour. Note that intermediate images from local builds are not considered for the ID lookups anymore. Fixes: containers#3359 Signed-off-by: Valentin Rothberg <[email protected]>
This is a surreal variant of #980. Please bear with me:
So far, so good. In particular, note the second (non-header) history line of the second command: it references
3b72fee4c9a3
which is i1, the image on which i2 is based.Now remove those images, pull in centos, and repeat:
Now look at the second (non-header) line of the second history command. I expected to see
ece3...
, the ID of i1. It now shows as<missing>
.podman-1.4.0-2.fc30.x86_64 and this time, 100% reproducible at least over about a dozen attempts.
The text was updated successfully, but these errors were encountered: