Add support to openshift-ansible to configure the registry backed by Ceph RadosGW available in an Overcloud deployment.
Testing shows that this works 'out-of-the-box'. Added some documentation in openshift-ansible: https://github.com/openshift/openshift-ansible/pull/8622
This BZ is documented from the openshift-ansible side: https://github.com/openshift/openshift-ansible/blob/master/playbooks/openstack/configuration.md#swift-or-ceph-rados-gw-backed-registry-configuration Its testing requires standing up an Overcloud with RadosGW enabled: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/deploying_an_overcloud_with_containerized_red_hat_ceph/#ceph-rgw
Should be in openshift-ansible-3.11.0-0.15.0
Per OCP program call on 21-SEP-2018 we are deferring Kuryr-related bugs to 3.11.z
This feature in the openshift-ansible installer has been present for a while but untested downstream until comment #1 (June 2018). It's not related to Kuryr either and it should work with 3.10 (probably with earlier releases?).
Adding Ben Bennett to follow up with you.
Checked with openshift-ansible-3.11.59-1 and Ceph RadosGW works well. openshift_use_swift_registry: True openshift_hosted_registry_storage_kind: object openshift_hosted_registry_storage_provider: swift openshift_hosted_registry_storage_swift_container: "openshift-registry" openshift_hosted_registry_storage_swift_authurl: "http://10.73.131.153:7480/auth/v1" openshift_hosted_registry_storage_swift_username: "openshift:swift" openshift_hosted_registry_storage_swift_password: "xxxxxxxx" openshift_hosted_registry_storage_swift_region: "{{ lookup('env', 'OS_REGION_NAME') }}" openshift_hosted_registry_storage_swift_tenant: "{{ lookup('env','OS_PROJECT_NAME') }}"
=========== registry-config =============== version: 0.1 log: level: info http: addr: :5000 storage: delete: enabled: true cache: blobdescriptor: inmemory swift: authurl: http://10.73.131.153:7480/auth/v1 username: openshift:swift password: Q7KiuZiQWcy9QFvIA3yVpqD32aRipTbl5IZRxSNf container: openshift-registry region: regionOne tenant: openshift-qe-jenkins auth: openshift: realm: openshift middleware: registry: - name: openshift repository: - name: openshift options: pullthrough: True acceptschema2: True enforcequota: False storage: - name: openshift ============= build log ==================== $ oc logs ruby-ex-1-build Using centos/ruby-25-centos7@sha256:3222ca6f052f3b3f8095b159d01dc4a73fdc307073e9445b283d391d3b39dad1 as the s2i builder image ---> Installing application source ... ---> Building your Ruby application from source ... ---> Running 'bundle install --retry 2 --deployment --without development:test' ... Warning: the running version of Bundler (1.16.1) is older than the version that created the lockfile (1.16.4). We suggest you upgrade to the latest version of Bundler by running `gem install bundler`. Fetching gem metadata from https://rubygems.org/.............. Using bundler 1.16.1 Fetching puma 3.12.0 Installing puma 3.12.0 with native extensions Fetching rack 2.0.6 Installing rack 2.0.6 Bundle complete! 2 Gemfile dependencies, 3 gems now installed. Gems in the groups development and test were not installed. Bundled gems are installed into `./bundle` ---> Cleaning up unused ruby gems ... Running `bundle clean --verbose` with bundler 1.16.1 Warning: the running version of Bundler (1.16.1) is older than the version that created the lockfile (1.16.4). We suggest you upgrade to the latest version of Bundler by running `gem install bundler`. Frozen, using resolution from the lockfile Pushing image docker-registry.default.svc:5000/default/ruby-ex:latest ... Pushed 0/10 layers, 1% complete Pushed 1/10 layers, 50% complete Pushed 2/10 layers, 50% complete Pushed 3/10 layers, 50% complete Pushed 4/10 layers, 56% complete Pushed 5/10 layers, 62% complete Pushed 6/10 layers, 67% complete Pushed 7/10 layers, 74% complete Pushed 8/10 layers, 90% complete Pushed 8/10 layers, 94% complete Pushed 8/10 layers, 98% complete Pushed 9/10 layers, 100% complete Pushed 10/10 layers, 100% complete Push successful
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-2019:0024
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days