Description of problem: This happens because in the past we had the role 'Member' , while in osp17.1 it expects the role 'member' in small letters, this gives a conflict. Version-Release number of selected component (if applicable): 16.2 > 17.1 How reproducible: 100% if you have OSP since 13 and have upgraded Steps to Reproduce: 1. # openstack overcloud upgrade run --yes --stack openstack05 --debug --limit allovercloud,undercloud --playbook all Actual results: 2024-06-15 16:45:36.450387 | e0071b6a-fbb0-5953-39aa-00000008e05e | FATAL | Check Keystone role status | undercloud | item=member | error={"ansible_job_id": "765084055976.244733", "ansible_loop_var": "tripleo_keystone_resources_role_async_result_item", "attempts": 1, "changed": false, "extra_data": {"data": null, "details": "Conflict occurred attempting to store role - Duplicate entry found with name member.", "response": "{\"error\":{\"code\":409,\"message\":\"Conflict occurred attempting to store role - Duplicate entry found with name member.\",\"title\":\"Conflict\"}}\n"}, "finished": 1, "msg": "Failed to create role member: Client Error for url: https://oscar23.tc.lab.corp:13000/v3/roles, Conflict occurred attempting to store role - Duplicate entry found with name member.", "tripleo_keystone_resources_role_async_result_item": {"ansible_job_id": "765084055976.244733", "ansible_loop_var": "tripleo_keystone_resources_role", "changed": true, "failed": false, "finished": 0, "results_file": "/root/.ansible_async/765084055976.244733", "started": 1, "tripleo_keystone_resources_role": "member"}} Expected results: No errors Additional info: Can be fixed with: # openstack role delete Member
(In reply to Grzegorz Grasza from comment #1) > I'm closing this, since we are very close to the last 17.1 release and I > won't be able to have a complete solution on time. > > The quick workaround is running: > > # openstack role delete Member > > The issue with running this indiscriminately during an upgrade to 17.1 is > that we don't know if the role was in any way modified between the upgrades. > It might be best to leave running this command to the end user, in the hope > that they know what they are doing (i.e. that they didn't do any changes to > the Member role). Can we add this to known issues into the documentation? Thank you
Workaround likely triggered bug #2309586 in Heat
The workaround "works" in the sense that we fail later on now with: ~~~ 2024-09-08 00:43:35.948587 | 9440c985-b930-3826-01ed-00000000262d | FATAL | Check Keystone user assignment to roles status | undercloud | item=swift | error={"ansible_job_id": "98192925416.91408", "ansible_loop_var": "tripleo_keystone_resources_user_role_async_result_item", "attempts": 2, "changed": false, "finished": 1, "msg": "Role member is not valid", "results_file": "/root/.ansible_async/98192925416.91408", "started": 1, "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": [], "tripleo_keystone_resources_user_role_async_result_item": {"ansible_job_id": "98192925416.91408", "ansible_loop_var": "tripleo_keystone_resources_data_user", "changed": true, "failed": 0, "finished": 0, "results_file": "/root/.ansible_async/98192925416.91408", "started": 1, "tripleo_keystone_resources_data_user": {"swift": {"project": "service"}}}} ~~~ Perhaps the customer should just tweak the following: ~~~ keystone_resources: swift: endpoints: public: {get_param: [EndpointMap, CephRgwPublic, uri]} internal: {get_param: [EndpointMap, CephRgwInternal, uri]} admin: {get_param: [EndpointMap, CephRgwAdmin, uri]} users: swift: password: {get_param: SwiftPassword} roles: - admin - member region: {get_param: KeystoneRegion} service: 'object-store' roles: - member - ResellerAdmin - swiftoperator ~~~ to: ~~~ keystone_resources: swift: endpoints: public: {get_param: [EndpointMap, CephRgwPublic, uri]} internal: {get_param: [EndpointMap, CephRgwInternal, uri]} admin: {get_param: [EndpointMap, CephRgwAdmin, uri]} users: swift: password: {get_param: SwiftPassword} roles: - admin - member region: {get_param: KeystoneRegion} service: 'object-store' roles: - Member <=================================================================== - ResellerAdmin - swiftoperator ~~~ Unless we can make the ansible module case insensitive ? I've tried reproducing this with the CLI and I can't , it's just with ansible that I can reproduce this issue . When I try to assign Admin instead of admin to a user in my 17.1 lab, it works but somehow ansible just doesn't like this.
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 (RHOSP 17.1.4 bug fix and enhancement 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-2024:9974
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days