Description of problem: https://github.com/openshift/ansible-service-broker/issues/644 What happened: In v3.7, if config broker-config with multi registry with the same name , the asb pod will fail with errror ERROR: Failed to read config file registry name must be unique But in v3.9 the asb pod will start successfully. And successfully loaded apbs from the last registry. Is it the expected feature ? @jwmatthews openshift v3.9.0-0.19.0 kubernetes v1.9.0-beta1 ASB: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/ose-ansible-service-broker:v3.9 [1.1.4] How to reproduce it: Config broker-config with: type: dockerhub name: test url: https://registry.hub.docker.com org: ansibleplaybookbundle tag: latest white_list: [.*-apb$] type: dockerhub name: test url: https://registry.hub.docker.com org: zjianbjz tag: latest white_list: [.*-apb$] Restart broker. Logs: [2018-01-16T09:19:30.029Z] [DEBUG] - APBs passing white/blacklist filter: [2018-01-16T09:19:30.029Z] [DEBUG] - -> zjianbjz/fail-apb [2018-01-16T09:19:30.029Z] [DEBUG] - -> zjianbjz/hello-world-db-apb [2018-01-16T09:19:30.029Z] [DEBUG] - -> zjianbjz/mediawiki-apb [2018-01-16T09:19:30.029Z] [DEBUG] - -> zjianbjz/postgresql-apb [2018-01-16T09:19:30.029Z] [DEBUG] - -> zjianbjz/hello-test-apb [2018-01-16T09:19:30.117Z] [DEBUG] - Registry::imageToSpec [2018-01-16T09:19:30.981Z] [NOTICE] - Broker successfully bootstrapped How reproducible: Every time
PR for fix is here: https://github.com/openshift/ansible-service-broker/pull/655
That is expected.
Verified base on Comment 3 and Comment 4.
Shawn, I have some concerns about the processing of the same registry name. I still cannot understand why we let it trigger the GO panic. I think we have many ways to process it（such as forbidden it） other than occur GO panic. The GO panic will break the ASB continuous running after all.
I have added an issue to discuss with the wider community about the behavior. https://github.com/openshift/ansible-service-broker/issues/753 I think that you bring up good points and we should have a larger discussion about this behavior and how we should handle it.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0489