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

improve imagestream metadata pull #10103

Closed
PI-Victor opened this issue Jul 29, 2016 · 5 comments
Closed

improve imagestream metadata pull #10103

PI-Victor opened this issue Jul 29, 2016 · 5 comments

Comments

@PI-Victor
Copy link
Contributor

Every time we create new image streams it takes a while to fetch the metadata from the registry.
This usually affects running extended tests locally, and also making oc start-build fail, because the specified tag for the imagestreamtag metadata defined in the buildconfig is not available yet.

Does it make sense to add some retry logic that would tell the build controller that the metadata for that specific imagestreamtag is being pulled (of course, only if that imagestreamtag is available)?
cc: @bparees @php-coder

@bparees
Copy link
Contributor

bparees commented Aug 1, 2016

Currently the way the API works the builder image reference must be resolved at the point in time at which the build is created, which means the build request API has to either be able to resolve the image (so it can create the build object) or it must fail the API request. There is no way for it to create the build object with a pending image resolution.

We do currently allow the output image to be resolved after the build object is created, and we might change the input images to work similarly in the future, see: #4518 (comment)

But it's a bit of a tradeoff.. Today if your buildconfig specifies an imagestream reference that is bad/invalid, you immediately get told, on starting a build, that you've done something wrong. If we tolerate bad/missing imagestreams (on the assumption that they might be created later), we'd create the build and put it in some sort of a pending/retry state while hoping for the imagestream (or imagestreamtag) to show up. That might happen (user is happy) or it might never happen (user is confused/unhappy until the build fails 30 mins later and they investigate why).

The main reason to do the tolerance/retry is so you can create a buildconfig + input imagestream in the same template and have it work (today if you did that it's likely the initial build from the buildconfig would fail since the input imagestream would be unavailable at the time the first build was created as triggered by the buildconfig's ConfigChangeTrigger)

@bparees bparees assigned bparees and unassigned PI-Victor Aug 1, 2016
@PI-Victor
Copy link
Contributor Author

just out of curiosity, instead of implementing a retry for now, does it make sense to return a more meaningful error message, instead of "imagestream not found" something like "imagestream data still populating" if the imagestreamtag is present?

@PI-Victor
Copy link
Contributor Author

though, that's a lot of hassle for... not much added value.

@bparees
Copy link
Contributor

bparees commented Aug 3, 2016

@PI-Victor yeah that's a lot of work for a pretty small window.

@bparees
Copy link
Contributor

bparees commented Oct 14, 2016

closing because i don't see us doing this. what we will do at some point is makine imagestream resolution part of a retry loop.

@bparees bparees closed this as completed Oct 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants