Earlier  
Posted Nick Remark
#openstack-nova - 2025-08-27
18:12:25 sean-k-mooney whoami-rajat_: exactly
18:12:49 whoami-rajat_ yeah there was no use case for glance so we never did it
18:13:03 whoami-rajat_ so what would be the next steps here?
18:13:14 whoami-rajat_ Cinder can't really adopt the new location APIs then, at least in 2025.2
18:13:49 sean-k-mooney the best outcome woudl be to add a new galnce section adn fallback to the keystone_auth or service_user section when not defiend
18:13:50 whoami-rajat_ if we revert the glance changes ^ which i think now is right to do
18:13:55 gmaan whoami-rajat_: sean-k-mooney before going to next step, I would like to know how it was working in stable/2024.2 where glance policy is same as sean-k-mooney revert and cinder failing in revert - https://github.com/openstack/glance/blob/stable/2024.2/glance/policies/base.py#L114
18:13:59 sean-k-mooney both of those will have the corect roels
18:14:25 whoami-rajat_ in 2024.2, we didn't adopt the location APIs
18:14:38 gmaan ohh
18:14:40 whoami-rajat_ so the feature in glance was merged in 2024.2 but we adopted it in 2025.2 (we=nova and cinder)
18:14:45 gmaan got it
18:15:12 sean-k-mooney the nova change mergd before the glance plicy change however right
18:15:18 whoami-rajat_ yes
18:15:26 whoami-rajat_ the policy change is recent, last week
18:15:27 gmaan best way to not break user and provide option to adopt new way also can be:
18:15:32 sean-k-mooney nova worked because we had an "admin" client
18:15:43 sean-k-mooney with the service role to use
18:16:03 gmaan 1. modify glance policy to service + admin right : this will allow cinder talk to glance with user token as it is currently
18:16:37 gmaan 2. add keystoneauth service user conf option in glance section in cinder.conf
18:16:51 gmaan 3. cinder pass that service user to glance which has service role
18:17:12 gmaan 4. ask operator to configure the same in their deployment via releasenotes or doc
18:17:32 whoami-rajat_ 3 and 4 could be the same cinder patch, which i can work on
18:17:44 gmaan 5, once we know operator are ok (or at least after one SLURP), make glance API to role:service only
18:18:08 whoami-rajat_ sounds good to me
18:18:43 sean-k-mooney that effectivly what we are doing in the nvoa changes for the external events api ectrs
18:19:01 gmaan yes, even we have the service user config option available for so ling
18:19:03 sean-k-mooney so yes i think thiat is the correc approch as well
18:19:19 whoami-rajat_ and if possible, can we document all the details we've discussed here in some RBAC doc, it's really confusing to know the "right" way to adopt a new thing like SRBAC which created the confusion for me at least
18:19:45 gmaan whoami-rajat_: I can propose the changes if you are ok and help in review? bit if you want to do that also fine
18:19:58 sean-k-mooney one thing to note
18:20:19 sean-k-mooney yuo can achive the same effect without have per service config seciton with auth info
18:20:34 whoami-rajat_ gmaan, sure, that will be faster as i can be one of the cores approving things
18:20:34 sean-k-mooney nova's approch si way more flexible and i think cleaner
18:20:37 gmaan whoami-rajat_: yeah, agree. that is my bad not to have proper doc for service role until I started working on those in nova, But I will do that as part of RBAC goal champion
18:20:42 gmaan whoami-rajat_: cool
18:21:03 sean-k-mooney but watcher ueses the keyston_authoken user/password for all service eclients
18:21:46 sean-k-mooney im not sayint that ig the correct thing to do but you already need a cinder user in that section and it should have the service role
18:21:57 gmaan sean-k-mooney: yeah, we can do that but we need to formalize that in most of the services. and I am not sure if there are use case of per service user permission in any demployment or they are ok with same user for all serviecsd
18:22:20 sean-k-mooney i think we shoudl not make that default
18:22:26 gmaan nova also has per service config users
18:22:33 sean-k-mooney having a per service config section i think is better
18:22:47 sean-k-mooney but you could have one fallback to the other if not configured
18:22:47 gmaan yeah, do not know what use we can break
18:23:06 gmaan ok, let me propose the changes today and will add you both as reviewer.
18:23:35 gmaan sean-k-mooney: you want me to do it in your glance revert or separate one as this is more than revert and add admin right also with serviec role?
18:24:20 sean-k-mooney gmaan: that valid. i have alreayd modifed it once. its up to you if you want to review the review/changeid go for ti
18:24:21 whoami-rajat_ modifications in the revert might not be clean and confuse people doing blame in the future, can we go for a new patch?
18:24:30 sean-k-mooney otherwise i can abandon it in favor of yours
18:25:08 whoami-rajat_ gmaan, just to be sure, you will be working on the cinder patch as well right? to use [glance] config section
18:25:18 gmaan ok let's do with new patch
18:25:43 gmaan whoami-rajat_: yes, whole series + devstack one and testing it together like I did for nova
18:25:51 whoami-rajat_ okay, thanks!
18:26:58 whoami-rajat_ thanks again gmaan and sean-k-mooney for the details, I will go now, let me know when the glance and cinder patches are ready and i can help in merging them
18:27:14 gmaan thanks, might be late for you
18:28:42 whoami-rajat_ generally I've stopped working late now but this was important so :D
18:28:45 whoami-rajat_ thanks again!
18:29:15 gmaan good for you :)
19:10:44 sean-k-mooney dansmith: so im more or less +w but before i hit it do you want to make this chagne https://review.opendev.org/c/openstack/placement/+/945465/comment/b1e034dd_f7b0b442/ or will i just approve as is
19:12:16 sean-k-mooney dansmith: the wrodign change is defintly minor enouch that i dont think it needs a respon and gibi resolved there nit when they +2'd
19:13:04 sean-k-mooney so in the absence of a prefence one way or another ill add +w before i finish for today
19:13:10 sean-k-mooney but jsut said i woudl ask
19:13:12 dansmith yeah, I dunno, I remember trying to figure out what to say there.. "does not increase existing overage" sounds a bit weird to me, even though I know what you mean
19:13:36 dansmith my preference is to +W so the code is right, and we can FUP the log text if we want
19:13:37 sean-k-mooney ya same that waws the second time i wrote that
19:13:50 sean-k-mooney ack ill do that so
19:15:04 sean-k-mooney done ok im going to try and finsin in the next 15 mins or so. i assume your going to backport those at some point
19:16:09 sean-k-mooney it could be nice to include that in 2024.1 before it goes unmaintained but that wont happen until 2025.2 is released so there si a little time still
19:25:48 dansmith yeah, should be backported
19:26:08 dansmith I guess I dunno how far it really needs, I was thinking just to 2025.1
19:27:14 opendevreview Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578
19:27:43 sean-k-mooney i woudl say what is ever open when you get aroudn to it but 2025.1 is a good baseline
19:28:05 sean-k-mooney by open i mean still stable/*
19:32:28 sean-k-mooney gmaan: same question to you https://review.opendev.org/c/openstack/nova/+/957578/comment/2b782393_1a20e07c/
19:32:57 opendevreview Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578
19:33:53 sean-k-mooney im +2 i can +w but if you feel like adressing the final nit then im ok with fast approving or having dan proxy
19:34:14 opendevreview Ghanshyam proposed openstack/nova master: Add service role in Nova policy https://review.opendev.org/c/openstack/nova/+/957578
19:34:30 gmaan dansmith: sean-k-mooney ^^ updated, I need to fix api-ref failure also. so this is updated one now
19:34:39 sean-k-mooney ah yes stephsn sample split patch merged
19:34:48 gmaan yeah :)
19:35:10 sean-k-mooney i was wonderign what the prior conflict was
19:47:17 gmaan dansmith: sean-k-mooney thanks. can you please review this devstack change also which is needed but tempest service role tests https://review.opendev.org/c/openstack/devstack/+/958612
19:51:56 sean-k-mooney im actully going to finish reviewing the first change in the sev serice but yes i can aftger
19:52:04 sean-k-mooney then ill call it a day.
19:52:28 sean-k-mooney my priorty tomorrwo will be to try and finish hte sev serise adn maybe the provider.yaml one
19:53:12 gmaan thanks
19:53:19 sean-k-mooney ok its litrally jsut adding thr service role
19:53:32 gmaan yeah, quick one :)
19:53:50 sean-k-mooney im +2 bnut shoud there be a comment above
19:54:04 sean-k-mooney or shoudl you also mention that the service role is added in 2025.2
19:54:17 sean-k-mooney basicly im wonderign why you left the first comment
19:54:53 gmaan i might just missed that, i can fix later once touching that file for related things
19:55:03 sean-k-mooney ack
19:55:15 sean-k-mooney i was just wonderign is there a convention that i shoudl be reviewing for
19:55:53 sean-k-mooney like in nova-next we sometime add comment when testing a future default so we know we can drop it form the job when it actully becomes the default
19:56:20 sean-k-mooney is noting the manager role so you can knwo when tempst can depend on it ?
19:56:56 gmaan yeah, that is helpful specially to know when to drop those things once they are in all supported releases
19:57:08 sean-k-mooney ack
20:18:19 sean-k-mooney ok first patch doen and it looks ok but i defintly dont have the brain power to go deeper in teh sev series today
20:18:30 sean-k-mooney ill try an complete it tomorrow

Earlier   Later