| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-02 | |||
| 16:37:55 | JayF | yeah | |
| 16:38:06 | JayF | honestly the culture here has always seemed to only count proof if it runs in CI | |
| 16:38:12 | JayF | so I wans't even going to attempt a manual test | |
| 16:38:26 | sean-k-mooney | well yes if its not in ci we assume its broken | |
| 16:38:45 | sean-k-mooney | but i jsut wanted to be sure we saw a speedup before we spent too much time on this | |
| 16:38:54 | sean-k-mooney | i.e. to make sure it really not a test artifact | |
| 16:39:20 | sean-k-mooney | so a one of manual test to confirm build confindence in the aproch | |
| 16:42:01 | clif | I don't mind attempting manual testing, I will say the change logically makes sense to me. Doing less work should *almost* always result in a speed increase | |
| 16:42:48 | sean-k-mooney | clif: yep what im hoping the manaul test will show is how big or small this is to the overall tiem | |
| 16:42:52 | sean-k-mooney | in a real system | |
| 16:43:10 | sean-k-mooney | the next speed up to try woudl be hte mutli threading patch | |
| 16:43:17 | sean-k-mooney | those are where i think most of it will come form | |
| 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 | |