-
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
[FEATURE] Implement Progress Details in podman pull API as occurs in docker pull API #24887
Comments
@rhatdan I would like to have your feedback here |
The API already supports the same progress details as the docker compat API endpoint. Just need to add |
I just run:
This is the output:
What I note is that, unlike docker API, the
and there is not the Extracting status details, as in docker API, for example:
and there are not the pull complete message after the extraction, as in docker, for example:
Is it possible to implement these missing details? |
The encoding thing should be an easy fix. The other messages at the end should be possible to add with the current info I think. PRs welcome. I don't think our backend makes any difference for "Extracting" so that info simply does not exists. No idea what "Verifying Checksum" means either. |
c/image and related repos do track a bunch of RFEs in this general area (e.g. containers/skopeo#658 , containers/image#2585 ), but short-term no work is happening in this area. (Historically, we were limited by a frozen API of the transport abstraction, making it impossible for individual transports to contribute progress information. That’s no longer the case, we do have an option to transfer more data between the generic copy code and transports. But none of that exists.)
(and the like…) I don’t consider that a valid way to consume Docker’s progress API. E.g. whether checksum verification is a separate phase or something happening concurrently with the transfer is an internal implementation detail, and depends on the source/destination. What do you need these details for? If the goal is to communicate progress to humans, there are various ways to structure a generic progress API to allow that (just a percentage, percentage + text (and localization!), some hierarchical structure — https://developer.apple.com/documentation/foundation/nsprogress is one of the more complex designs). Similarly, logs used for after-the-fact debugging need records of what happened, but not a commitment to any specific structure or order. I’m fundamentally opposed to making any promises on the structure of the copy process on the requested level of detail, constraining our ability to change the implementation — at least without any identified benefit to tying out hands that way. Keeping stable APIs is hard enough when talking about the actions, inputs, and outputs; making promises about logs would be way harder. |
Thanks for the detailed answer. And ok, I agree. The only thing to fix should be the |
The producer can produce either one, and I wouldn’t object to a PR that changes this just to save some trivial amount of bandwidth, but either way the parser needs to be able to parse JSON as specified ( https://github.com/moby/moby/blob/0342576056e80459c18cd78a2cdbf6f29961fe20/pkg/jsonmessage/jsonmessage.go#L145 allows for arbitrary JSON fields with arbitrary types to be included); we are not going to be adding special commitments to avoid valid JSON values for the benefit of incorrect parsers. |
Feature request description
Currently, by invoking podman pull API:
produces an output in JSON containing only
stream
field with no progress details, i.e.:This output is also different by the one produced by
podman pull
command that actually shows a progress bar:It would be very nice if this pull API could be improved in order to output progress details as occurs by docker pull API:
It can be useful for third-party programs using Podman SDK to manage or show the progress process in a flexible manner.
Suggest potential solution
My proposal is to replace
stream
element and use the same ones used in docker pull API, that are:status
progressDetails
current
total
progress
id
Have you considered any alternatives?
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: