Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-04-02
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
18:36:09 melwitt (the proposed patches not yet merged works with both modes)
18:36:30 sean-k-mooney ho do you knwo form one execution in a job where both deployment and host are allowed which the vm is using and how are you forcing that
18:36:47 melwitt or is your point that that would change since H was cut?
18:37:42 sean-k-mooney im saying we need to test with host mode (rpc copy) and with deployment mdoe secrest owned by nova)
18:38:02 sean-k-mooney and we need to ensure that one or the other is used durign the migrtion
18:38:14 melwitt there are currently separate tests for each mode and they both run in the same job, last I checked. I don't know if cutting the branch could have changed that
18:38:15 sean-k-mooney without lookign at somting like debug messages
18:38:56 sean-k-mooney oh they are forciign the mode via image properties
18:39:09 sean-k-mooney sorry flavor extra specs
18:39:12 sean-k-mooney not image proeprties
18:39:14 melwitt yeah you have to select the mode

Earlier   Later