Skip to content
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

Provide progress feedback and image size in imgpkg push #420

Closed
shaheerkootteeri opened this issue Jul 26, 2022 · 2 comments
Closed

Provide progress feedback and image size in imgpkg push #420

shaheerkootteeri opened this issue Jul 26, 2022 · 2 comments
Labels
carvel accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@shaheerkootteeri
Copy link
Contributor

shaheerkootteeri commented Jul 26, 2022

Describe the problem/challenge you have

We use imgpkg as library, and while using imgpkg push to upload a source bundle to a registry, sometimes it takes a while for the image to upload if the image size if large. We would like to show a progress bar to show the progress similar to imgpkg copy to show the user that the progress is made.

Describe the solution you'd like

Add a progress bar to show the progress being made and the image size as if it were an uploading data file. "305k/3000k - 10% ETA 30 seconds" this information is considered useful because it shows how much has been uploaded, how much must be uploaded, expresses that as a percentage for simplicity, and then shows the expected time it will complete.

Anything else you would like to add:
I was able to achieve the output progress bar same as that of imgpkg copy in imgpkg push by using registrywithprogress and the multiwrite function in imgpkg/plainimage/contents.go line # 49 (instead of writer.WriteImage), as the multi write already creates the channel to which updates will be sent while a transfer is in progress and log the same. However, I think the solution is to implement the progress logger for writeImage, same as that of MultiWrite.


Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help work on this issue.

@joaopapereira
Copy link
Member

I think it is a good improvement for our API side, for now, I believe that this change should only be done at API level. Not sure if we want to display the progress bar in imgpkg cli for single images, but with this functionality, I think we would be set for success if we want to do it.

Changing the WriteImage function from the Repository to add the ability to provide a channel to get the updates of the upload does sound like the best way to go(there are quite a number of interfaces that will have to be changed, but the best option nevertheless).

Going to accept this issue

@joaopapereira joaopapereira added carvel accepted This issue should be considered for future work and that the triage process has been completed priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. and removed carvel triage This issue has not yet been reviewed for validity labels Jul 26, 2022
@joaopapereira
Copy link
Member

This issue was solved in release 0.30.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
carvel accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

No branches or pull requests

2 participants