| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-02 | |||
| 16:43:26 | sean-k-mooney | out of the inifally few | |
| 16:43:33 | clif | yep, thats the one I want to look at next | |
| 16:43:49 | JayF | my downstream wanted to pull down that multithreading patch yesterday and I told em to wait for clif :D | |
| 16:44:24 | JayF | event-based updates for ironic node provision state is apparently a real need for them; it can take 20-30 minutes post-cleaning for a node to return to inventory | |
| 16:44:59 | clif | yea that's... not ideal to say the least | |
| 16:46:09 | sean-k-mooney | clif: for what its worth we often do add context like this to commti message if we have the data | |
| 16:46:11 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/427145 | |
| 16:46:49 | sean-k-mooney | its not really ment to be a rigorus test jsut indicitive | |
| 16:47:57 | sean-k-mooney | JayF: i need ot understand the delay there more but not today | |
| 16:48:08 | JayF | that periodic has to complete | |
| 16:48:16 | JayF | one of the big ones that are kinda awful on ironic | |
| 16:48:21 | sean-k-mooney | well it shoudl not really depend on that | |
| 16:48:28 | JayF | that's what I wanna fix :D | |
| 16:48:33 | sean-k-mooney | so i want to understand why | |
| 16:48:37 | JayF | same, I haven't gotten there yet | |
| 16:48:43 | JayF | and mostly am asking clif to get there :D | |
| 16:48:55 | sean-k-mooney | becuase when a node is cleanign it placement recouse provider shoudl jsut have reserved=total for the baremetal resocue class | |
| 16:49:23 | sean-k-mooney | but ironic can just set reserved back to 0 directly in placment when its done cleaning and its in the aviable state | |
| 16:49:56 | JayF | yeah, we don't do ANYTHING with placement now | |
| 16:50:00 | sean-k-mooney | so i just want to make sure we are not doing somethign dumb like recreating the RP and deleteing it based on the state | |
| 16:50:05 | sean-k-mooney | oh ok | |
| 16:50:15 | sean-k-mooney | so it relying on nova to poll ironic exclusivly | |
| 16:50:17 | JayF | yeah this is the stuff I was talking about for fixing for Ironic | |
| 16:50:18 | JayF | yep | |
| 16:50:25 | sean-k-mooney | and notice that the state has moved to avaible and we update it | |
| 16:50:30 | JayF | there are lots of opportunities for ironic to push via nova events api and/or talk to placement directly | |
| 16:50:39 | sean-k-mooney | ack ya | |
| 16:50:52 | sean-k-mooney | we can talk about that more whewn we both have more time | |
| 16:51:07 | sean-k-mooney | there defintly ways to short circut the perodic | |
| 16:54:17 | melwitt | dansmith, sean-k-mooney: I dunno if one of yall could help but there are a couple of patches needing a second +2 to start vtpm live migration testing in CI, devstack https://review.opendev.org/c/openstack/devstack/+/958254 and nova https://review.opendev.org/c/openstack/nova/+/978841 | |
| 16:55:41 | melwitt | on the devstack one mdevctl is included and IIRC it was something maybe sean had suggested on IRC to include but I don't think it's needed for vtpm. I can remove it if desired | |
| 16:56:07 | sean-k-mooney | sure i can look at them now | |
| 16:56:28 | sean-k-mooney | im pretty sure i have looked at or asked you about hte devstack one before | |
| 16:57:25 | melwitt | yeah same. thanks | |
| 17:02:33 | sean-k-mooney | do we also need https://review.opendev.org/c/openstack/devstack/+/968114 ? | |
| 17:03:26 | melwitt | oh hm, checking, I forgot about this one | |
| 17:05:08 | sean-k-mooney | https://review.opendev.org/c/openstack/devstack/+/968114/comment/fdbb7370_567faacf/ | |
| 17:05:18 | sean-k-mooney | so that will work but only on single node | |
| 17:05:25 | melwitt | I can't remember why I did that, must have been before I realized it wasn't needed | |
| 17:05:44 | melwitt | I don't find any patches that depends-on this | |
| 17:05:47 | sean-k-mooney | if we want to be able to enable this on a compute (without barbican) we woudl have to have a flag | |
| 17:05:49 | sean-k-mooney | ack | |
| 17:06:06 | sean-k-mooney | so the nova job you worte | |
| 17:06:17 | sean-k-mooney | is using barbican on the contoler | |
| 17:06:26 | sean-k-mooney | but disbaeld on the compute as we would expect | |
| 17:06:49 | sean-k-mooney | i wonder are we using the castalan optiosn or something for the key manager | |
| 17:07:50 | sean-k-mooney | melwitt: meta question is there a reason not to put this into nova-next or nova-alt-config? | |
| 17:07:52 | melwitt | it is using castellan but I don't remember where it's defaulted to that | |
| 17:08:30 | sean-k-mooney | we can move this testing later by the way im jsut confiming | |
| 17:08:54 | melwitt | sean-k-mooney: it requires nested virt in order to work, so I think I was likely thinking to make as small and short a job as possible to not have as much contention | |
| 17:09:33 | sean-k-mooney | ok i was thinking of movign the nova-next job ot use nested virt a while back | |
| 17:09:36 | melwitt | i.e. a longer job that requires nested virt will tie up the limited CI nodes that support nested virt | |
| 17:09:38 | sean-k-mooney | https://zuul.opendev.org/t/openstack/build/82adf7b225984621891eae9f930ba6ab/log/compute-host/logs/etc/nova/nova-cpu_conf.txt#59 | |
| 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. | |