Thanks. So the issue I'm facing with Magnum is not related to the member role. :)

Dmitriy Rabotyagov <noonedeadpunk@gmail.com> schrieb am 23. Nov. 2023 um 14:34:


No, I don't think that magnum user is ever connected to the _member_
role. Regarding magnum - it was affected by trusts, since we had
`cluster_user_trust = True` in [trust] section of magnum.conf.
So all trusts that were created for users were having _member_ role
for users and this was what we had to adjust as well.

чт, 23 нояб. 2023 г. в 13:05, Oliver Weinmann <oliver.weinmann@me.com>:

Hi,

Many thanks for your scripts. I tried to use your script but something is weird. It seems that no user in the admin project has the _member_ role assigned. So I don't understand how magnum should be affected by this. For testing I created a user test in the admin project in the default domain and this is shown as a member of the _member_ role. My OpenStack is connected to an AD domain via LDAP but here I have manually added all users to the member role.

Can someone please confirm that the magnum user is not assigned to the _member_ role?

Best Regards,
Oliver

Michael Knox <michael@knox.net.nz> schrieb am 16. Nov. 2023 um 14:42:


Thanks! I will use that as a starting point, appreciate the direction.

Cheers.
Michael

On Thu, Nov 16, 2023 at 8:04 AM Dmitriy Rabotyagov <noonedeadpunk@gmail.com> wrote:

Just to mention, all commands/scripts were made with minimal available
time on hands, so shouldn't be considered as a best or
production-ready approach but just drafts that were made in a couple
of minutes to address the issue. So review them carefully and optimize
them where possible.

So we did the following things:
* Assigned all users who had a _member_ role with member. This can be
done with a script like that [1]
* For application credentials, you likely need not only to add
"member" role, but also a "reader", since some Nova APIs require to
have a reader, and implied roles do not work as mentioned earlier:
MySQL> update keystone.application_credential_role set role_id = <role
member uuid> where role_id = <role _member_ uuid>;
$ for i in $(mysql -sN -e "select application_credential_id from
keystone.application_credential_role where role_id = '<role _member_
uuid>'"); do mysql -e "INSERT INTO
keystone.application_credential_role(application_credential_id,
role_id) VALUES (${i}, '<role reader uuid>')"; done
* For trusts:
MySQL> update keystone.trust_role set role_id = '<role member uuid>'
where role_id = '<role _member_ uuid>';



ср, 15 нояб. 2023 г. в 22:11, Michael Knox <michael@knox.net.nz>:
>
> 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.
>>
>>
>> вт, 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
>>
>>