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

Bug 1538321 - Continue to load specs even when a spec fails to load #682

Merged
merged 1 commit into from
Jan 25, 2018

Conversation

rthallisey
Copy link
Contributor

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

  • Be more fault tolerant to failed specs

Which issue this PR fixes (This will close that issue when PR gets merged)
fixes #681

@openshift-ci-robot openshift-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Jan 24, 2018
@rthallisey rthallisey added bug 3.9 | release-1.1 Kubernetes 1.9 | Openshift 3.9 | Broker release-1.1 labels Jan 24, 2018
@@ -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)
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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

@jmontleon
Copy link
Contributor

I like it, at least for the near term. It seems better than having a bad APB update potentially crashing brokers.

@jmrodri
Copy link
Contributor

jmrodri commented Feb 12, 2018

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
https://github.com/openshift/ansible-service-broker/blob/master/pkg/registries/registry.go#L136-L142

	// Debug output filtered out names.
	specs, err := r.adapter.FetchSpecs(validNames)
	if err != nil {
		log.Errorf("unable to fetch specs for registry %v - %v",
			r.config.Name, err)
		return []*apb.Spec{}, 0, err
}

jianzhangbjz pushed a commit to jianzhangbjz/ansible-service-broker that referenced this pull request May 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.9 | release-1.1 Kubernetes 1.9 | Openshift 3.9 | Broker release-1.1 size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Broker can't bootstrap if one of the APB's contains bad base64 data
5 participants