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

minikube start should wailt till "download-only" is finishing #11166

Closed
medyagh opened this issue Apr 21, 2021 · 4 comments · Fixed by #11223
Closed

minikube start should wailt till "download-only" is finishing #11166

medyagh opened this issue Apr 21, 2021 · 4 comments · Fixed by #11223
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Milestone

Comments

@medyagh
Copy link
Member

medyagh commented Apr 21, 2021

we could use our lock package https://github.com/kubernetes/minikube/tree/master/pkg/util/lock

to put a lock when minikube start --download-only happens

and then when minikube start runs when this lock exists will Wait for it to finish up to a reasonable time

@medyagh medyagh added kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels Apr 21, 2021
@afbjorklund
Copy link
Collaborator

afbjorklund commented Apr 25, 2021

I'm confused. You mean that minikube start exits currently, before the downloads have been completed ?

Or is this when running two minikube start at the same time, both using the same kubernetes version ?

@andriyDev
Copy link
Contributor

The latter. When running two instances of minikube start, only one image should be downloaded.

The original issue involved only locking when --download-only was involved, but perhaps this should be more generic and apply to any minikube start.

@afbjorklund
Copy link
Collaborator

afbjorklund commented Apr 26, 2021

Good thing, we had some other corruption of the downloaded images so I was starting to question everything :-)
(it was due to our download code not checking the checksum, before adding a resumed download to the cache)

@medyagh
Copy link
Member Author

medyagh commented Apr 27, 2021

/assign @andriyDev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants