Hi there,
What is the approach though?
Do we just script a change to move folks from _member_ to member? So no one in _member_?
We have a number of installs, but no magnum.
Cheers Michael
On Wed, Nov 15, 2023 at 10:02 AM Oliver Weinmann oliver.weinmann@me.com wrote:
Hi,
I just stumbled over this a couple of days ago. After I upgraded to Antelope a user reported that he is no longer able to see his instances in Horizon. After I figured out what was causing it, I simply changed the role of all users to include member. But now that you mentioned Magnum I wonder if I still have an issue because every new K8s cluster that I deploy suddenly has failed pods. :(
Best Regards, Oliver
Dmitriy Rabotyagov noonedeadpunk@gmail.com schrieb am 14. Nov. 2023 um 20:05:
Hey,
Theoretically that's a valid approach, but that won't work for application credentials due to the mentioned bug report in keystone [1]. Also, keep in mind trusts, especially if you're running Magnum.
We had to mess up with the keystone database and update the role UUID for application credentials and trusts where _member_ was assigned. And flush cache (memcached in our case) after doing that.
[1] https://bugs.launchpad.net/keystone/+bug/2030061
вт, 14 нояб. 2023 г. в 19:45, Christian Stelter refugee@last-refuge.net:
Hi!
As someone who hasn't yet delved very deeply into keystone and the policies of the individual OpenStack services, I wondered whether setting member as the implied role for _member_ could pick up all those users who didn't manage to rotate their application credentials before switching to Zed Antelope.
Is this a valid approach or could it cause problems?
Kind regards,
Christian