Proposal: Multiple Registry’s

[shawn-hurley]

Proposal: Multiple Registry’s

Goal: To allow users to provide multiple registries from the config. We should pull APB’s from all of the registries configured

Trello Card: https://trello.com/c/1KqTacLK/304-8-multiple-registry-adapters-configured-in-one-broker-instance

Changes to be made:

• app.App will be changed to have a slice of registries
• broker.Broker will be changed to have a slice of registries
• app.Config will contain a list of Registry Configs
• Bootstrap will loop through each configured registry and Load Specs
• Change registry config to have a Type and Name therefore users can name their registries.
• Combine logic of registries to simplify workflow - #180

Outstanding Questions

Questions with my thoughts underneath. I am looking for feedback on the options proposed.

1. How to deal with apb id collision

   • Easiest solution is to error out and blow up. I don’t think that an ID collision should cause the broker to die
   • Another idea is to warn if this occurs and take the one that is being entered.
   • Redesign the data storage, so that registry -> spec. This will change the ID’s of everything away from UUID OR we create a mapping in etcd

2. What happens if a registry fails to load.

   • Initial thought is to error out.
   • We can add a configuration that will allow an person to determine if a registry should fail the broker or not.
   • We can continue and warn if and only error if all registries have an error.

3. Should loading of specs be parallelised

   • Initial thought is simpler is easier to understand, we can go back and add goroutines at a later time.
   • If this is the case then we need to make sure 2 makes sense.

[shawn-hurley]

(8) Multiple Registry Adapters configured in one Broker Instance

[rthallisey]

How to deal with apb id collision

Easiest solution is to error out and blow up. I don’t think that an ID collision should cause the broker to die Another idea is to warn if this occurs and take the one that is being entered. Redesign the data storage, so that registry -> spec. This will change the ID’s of everything away from UUID OR we create a mapping in etcd

How much do we care about the IDs? In other words, are they being used for anything? If we load the same apb twice, that's the user's doing, but will it break anything?

[shawn-hurley]

I agree it won't break anything that we are doing unless we make it break.

Easiest solution is to error out and blow up. I don’t think that an ID collision should cause the broker to die

I think the other two solutions are the ones that make the most sense. Either to make each registry have its own name and directory in etcd or just warn the user that we are overwriting a spec.

I don't think the solution is to silently do something and not mention it somewhere IMO

[jmrodri]

FWIW the service broker api spec says the following about the values that need to be returned from the catalog api:

https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#service-objects

[jmrodri]

I would make the failure be configurable. As a developer I might want to have false for dockerhub, but true for rhcc or whatever I want it to be true and fail.

registry:
   - failOnError: true

[jmrodri]

For now I would not parallelize it but code it expecting it to be in the future.

[shawn-hurley]

FWIW the service broker api spec says the following about the values that need to be returned from the catalog api

Are you referencing this:

An identifier used to correlate this service in future requests to the broker. This MUST be globally unique within a platform marketplace. MUST be a non-empty string. Using a GUID is RECOMMENDED.

I think the above proposal would meet such a requirement. We would still be using a GUID it would just be prepended by the registry (etcd dir) name I.E rhcc/. We would also need to display which registry each APB is from in the service catalog as well.

I could see this being overkill for now, but I think if any complex use of registries (i.e development -> staging -> production registries) and having a single broker pulling all those images we would want to give the ability for a user to see all the registries APBs IMO.

If this is not a valid use case that we want to worry about then I vote to just warn we are overwriting and re-visit this if it comes up.

[jwmatthews]

Let's be sure we are able to handle a use case:

RHCC (configured to registry.access.redhat.com) + Dockerhub (configured to org1) + Dockerhub ( configured to org2)

We want to support both multiple adapter types as well as multiple registries.

[shawn-hurley]

merged with #271