| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-02 | |||
| 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 | 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: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: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 | |
| 18:27:26 | gmaan | yeah | |
| 18:27:44 | sean-k-mooney | so we will eenither need to have a new config for the aviabel deployment modes | |
| 18:27:47 | sean-k-mooney | and skip based on taht | |
| 18:28:03 | sean-k-mooney | which woudl be my prefernce in this case since ist a list in nova | |
| 18:28:21 | sean-k-mooney | or boolean values | |
| 18:28:51 | sean-k-mooney | the reason im askign is becasue i dont see the poplicies defiend here https://review.opendev.org/c/openstack/nova/+/978841/6/.zuul.yaml#424 | |
| 18:30:18 | sean-k-mooney | looks like tempest currently just has a bool for is it suprptoed at all https://review.opendev.org/c/openstack/tempest/+/957475/31/tempest/config.py | |
| 18:30:30 | melwitt | ah it's bc during review we changed to make the parent job devstack-whitebox-multinode and they are set there already | |
| 18:30:31 | sean-k-mooney | which is ok for now but we will need to evolve that | |
| 18:30:39 | melwitt | *whitebox-devstack-multinode | |
| 18:31:37 | sean-k-mooney | it also only hass a bool | |
| 18:31:39 | sean-k-mooney | https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/whitebox_tempest_plugin/config.py#L371-L373 | |
| 18:31:49 | sean-k-mooney | not which mode the host is in | |
| 18:32:01 | sean-k-mooney | i guess | |
| 18:32:20 | sean-k-mooney | from a pure tempest poitn of view it does not care | |
| 18:32:28 | melwitt | yeah, since we split the policies we'll need a separate gate for the hibiscus ones. if it had not split we would just have the bool. but alas | |
| 18:32:39 | sean-k-mooney | but we cant test both mdoes properly at the same time | |
| 18:33:15 | sean-k-mooney | melwitt: so the point im tryign to make is we need to be able to test botht the case wehre nova owns the secrete | |
| 18:33:23 | sean-k-mooney | and the case wehre the user does but we can copy it | |
| 18:33:33 | melwitt | yeah I was thinking of the current config of the supported modes is in whitebox https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/.zuul.yaml#L109 so we didn't have to do it in the nova .zuul.yaml | |
| 18:33:41 | sean-k-mooney | and i dont see how we can do that without either 4 nodes | |
| 18:33:49 | sean-k-mooney | or reconfigurign the nova config | |
| 18:34:35 | sean-k-mooney | we used ot reconfigure the nova config in whitebox and still can durign test but we tried to move aways form that for stablity reasons | |
| 18:35:52 | melwitt | it currently works to test both modes so I'm not yet sure why we would need to change config but I'm sure i'm missing something | |