On Tue, 2024-08-13 at 17:39 +0900, Masahito Muroi wrote:
Hi Nova and Keystone folks,
I'd like to get your feedback for the bug[1] and the commit[2]. We use Keystone as company internal role management system and hit the issue frequently.
The commit is to change instance_system_metadata table schema, but it could be too big change only for the long role list. changing the instnace_system_metadata schema form nvarchar 255 to text is not really an option.
it woudl be a very large data migration for exsting user as you would be moving the sting data form bign stored inline in the table to being stored out of line as seperate files on disk that woudl signifcalty impact the performance so that approch is not viable IMO
Another idea I can imagine is to introduce "store_boot_roles" boolean configuration to store the boot_roles or not. IIUC, the boot_roles is used only by a specific vendor data in the metadata api.
that is also not really a good option as this data is used form muplile location and reuqiring you sett the same config option on the compute conductor scheduler and api the same is very error prone.
If there is another good value to store from Keystone side, I'm happy to use the value instead of role name, too.
im not actully sure why we are storign the roles at all in the instance_system_metadata. the roles are not an atribute of the vm they are an atirbute of the user token used to create the vm as such i woudl argure we likely shoudl not be storing them at all since that data could be stale if we ever read it again later. since we cant rely on it to be current we shoudl not store it. however im not sure why we orginally stored this so woe woudl need to investiagte that.
1. https://bugs.launchpad.net/nova/+bug/2075100 2. https://review.opendev.org/c/openstack/nova/+/925163
thank you, Masahito