| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-02 | |||
| 17:09:51 | sean-k-mooney | so i can see the backend is set correctly | |
| 17:10:10 | sean-k-mooney | but we do not have a barbican section defiend | |
| 17:10:27 | sean-k-mooney | oh | |
| 17:10:30 | sean-k-mooney | i know why | |
| 17:10:54 | sean-k-mooney | melwitt: so today we are usign the user token to talk to barbican | |
| 17:11:03 | sean-k-mooney | we only need that config secton for the deployment mode | |
| 17:11:08 | sean-k-mooney | and that not merged yet | |
| 17:12:12 | sean-k-mooney | my expection is we are currently just lookign up the barbican endpoing form teh tokens service catalog | |
| 17:12:15 | melwitt | I think maybe it was that we settled on using the [service_user] config section instead | |
| 17:12:24 | sean-k-mooney | an no | |
| 17:12:30 | sean-k-mooney | well as a fallback | |
| 17:12:40 | sean-k-mooney | but not as the primay | |
| 17:12:47 | melwitt | because there are no patches currently depends-on it so it's not being used by the patches I have up that are testing deployment mode | |
| 17:13:10 | melwitt | it is the primary, there was a lot of discussion on it and that's where we ended up | |
| 17:14:08 | sean-k-mooney | have we merged that because i feel like i have have proably be -1.5 on that if i was invoveld | |
| 17:14:10 | melwitt | comment thread here https://review.opendev.org/c/openstack/nova/+/942021/45/nova/context.py | |
| 17:14:44 | melwitt | yeah it's merged | |
| 17:14:48 | sean-k-mooney | we shoudol not be suign the service_user section to tlak to barbicn or any ohter service in my opinion | |
| 17:15:21 | melwitt | why do I always work on the most controversial stuff (haha) this and ephemeral encryption I swear everyone has a different opinion | |
| 17:15:28 | sean-k-mooney | we cant assume that barbican is in the same region for one | |
| 17:17:08 | melwitt | I mean ... if [service_user] is meant to talk to all of the services, how can it do that if the region isn't the same? that section is used for all the service token stuff | |
| 17:17:17 | sean-k-mooney | its not | |
| 17:17:47 | melwitt | "send_service_user_token = True" ? | |
| 17:17:51 | sean-k-mooney | service user is for one thing and one thinkg only generating a service token to do lifetime exstions fo the user/admin token | |
| 17:18:01 | sean-k-mooney | yes | |
| 17:18:09 | melwitt | yeah, I know. I think all of that is discussed in the thread | |
| 17:18:27 | sean-k-mooney | right so usign it to create a user token for nova is not ok | |
| 17:19:04 | melwitt | personally, I don't really care which section it was but I tried re-using the other ones and it failed massively. so it's either [service_user] or we make a new [barbican] section | |
| 17:19:22 | sean-k-mooney | yep we shoudl have a new barbican section | |
| 17:19:33 | sean-k-mooney | that expclity what im suggeting | |
| 17:19:53 | melwitt | yeah, and I did propose that but I can't remember how it got disagreed about | |
| 17:20:09 | sean-k-mooney | i would prefer if that was also a hard requiremt to use this | |
| 17:20:37 | sean-k-mooney | i.e. make it an error to have deployment enable and not ahve the barbican section defiend if the backend is set to barbican | |
| 17:21:05 | melwitt | I guess we could still change it given that we don't support 'deployment' live migration yet and so it's left out of the docs for now | |
| 17:21:14 | sean-k-mooney | its not to late to fix this we dont ahve any code usign yet right looking at the serises | |
| 17:21:20 | melwitt | but I really need people to get on the same page and agree because this majorly sucks for me | |
| 17:22:10 | melwitt | I'll add it as a ptg topic, since that's happening soon anyways | |
| 17:22:35 | sean-k-mooney | i was also talkign to gmaan about incorrect use fo service tokens in other project | |
| 17:23:01 | sean-k-mooney | we caught an unintiall issue with glance/cidner very close to the ff | |
| 17:23:21 | sean-k-mooney | we also need to envutaly clean up the workaroudn we have in cinder for voluem attafchments | |
| 17:24:13 | sean-k-mooney | i think gmaan wanted to write ups some docs on this to calrify a few thing but i might be miss rememebrign | |
| 17:24:55 | melwitt | ack | |
| 17:46:00 | sean-k-mooney | we do have a barbical sectionin our cofnig by the way | |
| 17:46:02 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#barbican | |
| 17:50:20 | gmaan | sean-k-mooney: here is summary on that but yes as melwitt said we can discuss it in PTG also and I can work on document on what to use when (once we all agree on it) | |
| 17:50:47 | gmaan | keystone_authtoken: is used only at API layer so vTPM usage is from nova compute so it is not possible to use in this case. | |
| 17:52:03 | gmaan | barbican user: if i am not wrong here, vTPM secrets are owed by nova service user not barbican service user so user configured in barbican section is not suitable to use in vTPM. That is my understanding during that discussion . melwitt correct me if that is wrong. | |
| 17:52:31 | sean-k-mooney | the user configred in teh barbicna section shoudl be nova | |
| 17:52:35 | sean-k-mooney | it shoudl nto be barbican | |
| 17:52:38 | gmaan | why | |
| 17:52:52 | sean-k-mooney | because nova shoudl never have the user/password fo another service | |
| 17:53:17 | gmaan | it should be barbican given user to nova so that nova can talk to barbican. same as nova service user is configured in cinder conf nova section | |
| 17:53:18 | sean-k-mooney | that is one of our security hardign recommedation and someitn we have been plannign to fix in devstack for a while | |
| 17:53:55 | sean-k-mooney | gmaan it is the user thant nova shuodl use to talk to barbcina yes. conventionally nova but it can be any user and that is the user who shoudl own the secret | |
| 17:54:02 | sean-k-mooney | whaterver there name maybe | |
| 17:55:32 | gmaan | 1 sec, I think i mixed it | |
| 17:56:12 | sean-k-mooney | i condire it incorect to use the service_user section to create the primary token for any request period | |
| 17:57:40 | gmaan | yes, barbican section should have nova service user. i saw the devatack example which are all mixedup | |
| 17:58:00 | gmaan | let me check comments again why we did not use barbican section | |
| 17:58:10 | sean-k-mooney | its because fo castalan | |
| 17:58:16 | sean-k-mooney | i think | |
| 17:58:21 | sean-k-mooney | i need to doubel check | |
| 17:58:50 | sean-k-mooney | we have both a barbican and barbican_service_user section today | |
| 17:59:11 | sean-k-mooney | barbican is almost complete but its not the full set of keystone auth options | |
| 17:59:33 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#barbican-service-user | |
| 18:00:12 | sean-k-mooney | the option are splict between the two sectiosn today | |
| 18:01:30 | sean-k-mooney | https://github.com/openstack/nova/blob/653f7a42d0c9db126c0d5eb94af8945732f68d72/releasenotes/notes/deprecate-barbican-config-options-68ae65643ac41e2f.yaml#L4 | |
| 18:04:08 | gmaan | right, becauwe of castalan. so if itis from API interaction only them keystone_authtoken is right section which has the nova user but when it is way wider than just API, service_user is the only nova service user exist to use | |
| 18:04:27 | sean-k-mooney | right which we cant use | |
| 18:04:50 | sean-k-mooney | so we need a new section be it barbican_client or we use teh castalan options | |
| 18:05:05 | gmaan | i know that is what i mentioned in your discussion also, we need to get an agreement on which one to use when, but in current design what other option we have? | |
| 18:05:27 | sean-k-mooney | so i dont think we shoudl provceed with the current design | |
| 18:06:15 | sean-k-mooney | the option are use both sectionvs form castalan or add a new barbican_client option or fix the option in castalane so that the brbican options are not splict | |
| 18:06:26 | sean-k-mooney | fixing castalan would be my prefernce | |
| 18:06:45 | sean-k-mooney | then we can just use the barbican section dirctly | |
| 18:09:35 | gmaan | yeah, if we fix the castalan or add a new section then we can use but i feel we need to make a general agreement on 'why not to use service_user' | |
| 18:10:36 | sean-k-mooney | because it only for token lifecycle exteion and we need to be able to have diffent CA/region/users configured for every service we talk too | |
| 18:10:36 | gmaan | one use case of that is for token expiry which can be send along with user token but also a user to interact other serviecs if nova compute (other than API) service want | |
| 18:11:18 | sean-k-mooney | i know there is an assumtion in general that the service_user user will have the service role and or admin role | |
| 18:11:23 | sean-k-mooney | but we cant actully rely on that | |
| 18:11:26 | gmaan | i agree for that. here specific case if comoute service want to talk where our existing normal service users per service section does not work | |
| 18:12:04 | gmaan | bcz they are registered and tied at API service level for example keystone_authtoken | |
| 18:12:18 | sean-k-mooney | per service section are not needed if we are suign a users token because we can use that tokens service catalong to find the endpoint | |
| 18:12:28 | gmaan | anwyays, let'sa discuss it in PTG and see if we can get agreement | |
| 18:12:32 | sean-k-mooney | although even the we do uses the cofnig sectoin to knwo which endpoithn we talk too | |
| 18:13:02 | sean-k-mooney | ac | |
| 18:13:04 | sean-k-mooney | ack | |
| 18:13:42 | gmaan | accordingly I can work on some doc on that, which is what i mentioned to you about doc bcz it is not consistent and agreed | |
| 18:14:47 | sean-k-mooney | anyway melwitt we got side tracked | |
| 18:14:54 | sean-k-mooney | i approved the devstack patch | |
| 18:15:38 | sean-k-mooney | i think once i look at the tempest resut im ok eot start ith the nova-vtpm job as seprate but i would really prefer to consoldiate it with nova-next or nova-alt-config i think in the future | |
| 18:23:10 | melwitt | thanks sean-k-mooney | |
| 18:24:26 | sean-k-mooney | so its currently runnign 3 live migrtiton tests https://ee4ee966b92d55ec0885-e7631c5842b30279943de651c580e67f.ssl.cf2.rackcdn.com/openstack/82adf7b225984621891eae9f930ba6ab/testr_results.html | |
| 18:24:54 | sean-k-mooney | that usign the host policy right | |
| 18:25:07 | sean-k-mooney | where we copy the secret over rpc | |
| 18:25:47 | sean-k-mooney | and i assume we will have additoanl tempest test for deployment eventually with a new compute feature flag or a change to the tempest config to enable those later | |
| 18:25:50 | melwitt | yes | |
| 18:26:11 | melwitt | yes, those are proposed already bc what I did was split them out when we weren't going to get to merge deployment mode yet | |
| 18:27:05 | sean-k-mooney | ack but they will need to be gated by a new flag in the compute_feature_flags in tempest or similar in whitebox | |
| 18:27:24 | sean-k-mooney | becasue master tempet need to supprot the older branches i.e. 2026.1 | |