Description of problem: When deploying RGW via director, it requires a restart to work otherwise we have a 401 Unauthorized for any swift request. Version-Release number of selected component (if applicable): RH OSP10 last rhos-release How reproducible: Deploy RGW via director Steps to Reproduce: 1. Deploy RGW via director openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates --ntp-server 10.16.255.1 --control-flavor control --control-scale 3 --compute-flavor compute --compute-scale 1 --ceph-storage-flavor ceph-storage --ceph-storage-scale 3 --neutron-tunnel-types vxlan --neutron-network-type vxlan -e /usr/share/openstack-tripleo-heat-templates/environments/manage-firewall.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e templates/network-environment.yaml -e templates/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-radosgw.yaml 2. source overcloudrc 3. run any swift request Actual results: undercloud$ swift list Account GET failed: http://192.168.122.109:8080/swift/v1?format=json 401 Unauthorized [first 60 chars of response] {"Code":"AccessDenied","RequestId":"tx000000000000000000001- Failed Transaction ID: tx000000000000000000001-0057fd1147-8533-default Expected results: Expect a 200 return code from swift API. Additional info: Restarting RGW on all controllers solves the issue. It seems RGW is started with partial config with missing parameters like : rgw_keystone_token_cache_size = 500 rgw_keystone_url = http://172.16.0.23:35357 rgw_s3_auth_use_keystone = True rgw_keystone_admin_token = cwDxbZsRGqYJGM4tYAkuQWuPq rgw_keystone_accepted_roles = admin,_member_,Member As if puppet-ceph writes basic ceph.conf, then RGW starts and finally puppet-ceph finishes the ceph.conf config generation. Has lend a typical environment to Sebastien Han, he should be able to provide more in depth details. Cheers, Greg
There's a patch pending for review upstream [1] puppet-tripleo configures and start radosgw in step 3 and then sets the keystone parameters in step 4, but the radosgw service is not notified of configuration changes and is not restarted to pick the changes. The patch [1] allows to notify/restart the service when configuration changes. [1] https://review.openstack.org/388080
Tested and validated! LGTM
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://rhn.redhat.com/errata/RHEA-2016-2948.html