-
Notifications
You must be signed in to change notification settings - Fork 84
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
Bug 1538321 - Continue to load specs even when a spec fails to load #682
Conversation
@@ -111,8 +111,7 @@ func (r DockerHubAdapter) FetchSpecs(imageNames []string) ([]*apb.Spec, error) { | |||
for _, imageName := range imageNames { | |||
spec, err := r.loadSpec(imageName) | |||
if err != nil { | |||
r.Log.Errorf("unable to retrieve spec data for image - %v", err) | |||
return specs, err | |||
r.Log.Errorf("Failed to retrieve spec data for image %s - %v", imageName, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally don't like this approach.
This needs to be changed on the interface, if we are never going to return something went wrong I think we should force that across all adapters IMO. I think this is a conversation that we should have about what we expect from the registry perspective if an adapter throws an error here. Do we want to respect it? do we want the adapter to handle its own errors and just pass us a clean list of specs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with moving out to the interface is with the local_openshift_adapter unfortunately. It has a few places where we need to respect the errors for, like creating the openshift client, checking the ip of the docker-registry, and loading images from the docker-registry.
I think this is a conversation that we should have about what we expect from the registry perspective if an adapter throws an error here. Do we want to respect it? do we want the adapter to handle its own errors and just pass us a clean list of specs?
I think it's worth having. In the near term though (3.9), this PR will ignore any failed specs which will prevent anyone from hitting the issue. I think it's worth coming back to do more thorough improvement on this. We can do things like log how many bad specs were found in a repo and define a firmer policy on handling registry errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 that sounds reasonable to me
I like it, at least for the near term. It seems better than having a bad APB update potentially crashing brokers. |
It's too late for my comments on this but instead of eating the errors we should've fixed the registry.go code to not lose all of the specs
|
Describe what this PR does and why we need it:
When a spec fails to load, it will cause all the specs from that registry adaptor to be ignored. If the broker is configure to look at only one adaptor, it causes the broker to fail.
Let's log the spec failure and continue processing valid specs.
Changes proposed in this pull request
Which issue this PR fixes (This will close that issue when PR gets merged)
fixes #681