Improve progress bars, and update mpb #1530
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
… tiny bit Should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
|
LGTM |
vrothberg
approved these changes
Apr 27, 2022
There was a problem hiding this comment.
Changes LGTM.
Something I would love to see in the UX is to draw all progress bars before pulling. Currently, a bar is drawn the moment we start pulling the blob.
It would be nice to have them all drawn before. Unrelated to this PR though.
@mtrmac feel free to merge.
That’s a good idea — but not something I want to take on during this PR, which is primarily so that we can update the MPB dependency and don’t have to worry about a c/image user updating MPB itself, breaking the code. So, I have filed #1532 for that. One issue resolved, one issue added, so it goes… |
…s.go Let's try to make copy.go shorter, and consolidate progress bar code to new copy/progress_bars.go. First, move the code from copy.go. Only moves unchanged code, should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Second part: Move blobChunkAccessorProxy to the newly established progress_bars.go. Only moves unchanged code, should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to cleanly differentiate the code related to chan<- types.ProgressProperties from the code related to progress bars. Only moves unchanged code, should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The same srcInfo.size was passed to createProgressBar, so this does nothing at best if size is known; if it is unknown, it seems to effectively also be a no-op with a recent version of mpb (it sets the total value to 0, the current progress at the time, but it doesn't enable auto-complete, so it doesn't make a difference). Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Already draw the progress bar before opening the source's layer or config blob, so that the users can have a visual indication of something related to that blob happening if it takes too long. (For the .ConfigBlob() call, this might not make a difference, because in _some_ cases we trigger reading the config via .OCIConfig in checkImageDestinationForCurrentRuntime(), and the config blob is cached, but it might make a difference in the other cases, and it doesn't hurt in this one.) Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In particular, if the source is compressed, track the full size of the original compressed blob in the progress bar, even if the decompressed version has a different size (e.g. because the encryption adds a header or a MAC). This original size is easy to determine and eaiser to explain to users; so let's do the simple thing. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This will allow us to add more state and methods to the bar object, without copy&pasting. For now, this just wraps one pointer in another, and should not change behavior. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This correctly handles both the "size known" and the "size unknown" cases, and because we now record the originally-configured progress bar size in the progressBar struct, the caller doesn't need to track it. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
If srcInfo.Size == -1, the progress bar is not showing the refill value anyway (customPartialBlobDecorFunc is only used if size is known), so don't bother calling this function with nonsense data, if anything, at least to emphasize that this condition is, in principle, possible. Should not affect behavior, hopefully. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... so that we test all of this with the new semantics. Signed-off-by: Miloslav Trmač <mitr@redhat.com>
mtrmac
force-pushed
the
progress-updates
branch
from
b4fdf40
to
3a9550c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Resolves #1464 (see there for rationale), and replaces #1473 . The general principle is that progress bars track object size at the source transport now, consistently everywhere.
Also various other related cleanups in this area.
See individual commit messages for details.