Hi Oliver, Thanks. It's good to know we are not the only one who had the problem. I think the point you mentioned about _member_ role may be the trigger for our problem. As reported in another somewhat duplicated email to the list (because I realized that my first email was sent from an email not registered into the list and I thought it would be rejected), I think I identified that Keystone and Cinder (the other upgraded services) were not affected because they still seem to have the old rules present in the policiy where Nova and Glance don't. For the time being, as a workaround, we decided to redefine the rules project_member_api and project_reader_api to include role:users, the role all non-admin users have. We'd like to move back to using a standard role understood by the standard policies. We thought that renaming role "users" into "member" would be enough but it didn't work and I'm still interested to understand why and how to have it recognized as the "member" role. We could also do what you did, create a new role and give it to anybody with a "users" role but I've the feeling it is an overkill: whats the difference with renaming a role so that it has the proper name. I also have an issue with Keystone policy where an attempt to implement the same approach results in breaking the policy for everybody, including admins... Probably a trivial mistake but I was wondering if someone know how to theck if a policy file is correct or get a report about errors... Suggestions welcome! Best regards, Michel Le 05/06/2024 à 06:22, Oliver Weinmann a écrit :

Hi Michel,

I think I had the same issue after the upgrade. If I remember correctly this is due to the fact that the role _member_ has been deprecated at some point. By default all users are assigned to this role. After the upgrade I had to assign the member role without the _ to all users and that fixed it.

Cheers, Oliver

Von meinem iPhone gesendet

...

Am 04.06.2024 um 23:31 schrieb Michel Jouvin <michel.jouvin@pm.me>:



Hi,

I just upgraded Nova/Cinder/Glance of our production cloud from Yoga to Antelope (after upgrading Keystone yesterday) and since the upgrade, users who are not admin cannot do anything basically, despite we changed nothing to service configuration or user's roles since Yoga. We enabled scoped tokens a while ago (several months).

For (bad) historical reasons,  the role "member" was called "users" but it had no impact (I was surprised), despite we are using standard policies. We thought it may be a consequence of this and we renamed the role back to "member". It was not enough to fix the problem, even after restart memcached on all servers just in case.

We thought that there was may be some caching done somewhere with the old role name and modified slightly the policy rules defining what is a member or read with:

"project_member_api": "(role:member or role:users) and project_id:%(project_id)s" "project_reader_api": "(role:reader or role:users) and project_id:%(project_id)s"

It first works but the change was reverted by mistake and now it doesn't work anymore.

I am really completely stuck, without any clue about what happen and on how to troubleshoot it. I googled a bit but was not able to find something looking similar...

*Any help would be greatly appreciated*. Best regards,

Michel

-- Michel