-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Comments
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) |
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? |
though, that's a lot of hassle for... not much added value. |
@PI-Victor yeah that's a lot of work for a pretty small window. |
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. |
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
The text was updated successfully, but these errors were encountered: