| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-18 | |||
| 08:44:32 | bauzas | fun, can't log into the openstack wiki | |
| 08:44:35 | bauzas | anyone else ? | |
| 08:47:35 | Uggla | bauzas, same for me apparently | |
| 08:47:52 | bauzas | I left a ping in #openstack-infra | |
| 08:48:02 | Uggla | bauzas, nop it is slow but ok | |
| 08:48:26 | bauzas | we should move the wiki pages to the nova internal docs eventually, and just leave the meeting agenda as an etherpad | |
| 08:48:50 | bauzas | no need for us to continue to run a wiki | |
| 08:49:08 | gibi | for me it is not slow but actually not log in just put me back to where I started the login process | |
| 08:49:14 | bauzas | and many times it's either slow or broken | |
| 08:49:23 | bauzas | gibi: same behaviour here | |
| 08:50:03 | bauzas | I'm no longer a PTL but I have time :) | |
| 08:51:31 | Uggla | login is working but it is very sloooow. | |
| 09:25:48 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944840 | |
| 09:25:51 | opendevreview | OpenStack Release Bot proposed openstack/placement stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944841 | |
| 09:25:53 | opendevreview | OpenStack Release Bot proposed openstack/placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944842 | |
| 10:06:16 | opendevreview | Merged openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713 | |
| 12:43:46 | opendevreview | Merged openstack/nova master: Bump MIN_{LIBVIRT,QEMU} for "Epoxy" https://review.opendev.org/c/openstack/nova/+/942871 | |
| 12:44:39 | frickler | \o/ | |
| 12:48:04 | opendevreview | Merged openstack/placement stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944840 | |
| 12:59:41 | opendevreview | Merged openstack/placement stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944841 | |
| 12:59:43 | opendevreview | Merged openstack/placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944842 | |
| 13:57:28 | gibi | bauzas: FYI this is the PCI in Placement fix we discussed before in our planning. https://review.opendev.org/q/topic:%22bug/2098496%22 Dan is already +2. I know that we are in the RC quite period so I'm just asking for review, but I'm OK to keep this open until the final release and then land it on master and backport to stable 2025.1 | |
| 13:57:36 | gibi | no need for an RC2 just for this | |
| 14:04:37 | dansmith | bauzas: it's pretty nasty since it consumes more PCI devices than the user asked for, so we definitely need to backport that if no rc2 | |
| 14:05:07 | dansmith | usually the justification for an rc2 is that it fixes a regression that would be in this release.. gibi when did this bug get introduced do you know? | |
| 14:05:14 | dansmith | I assume before this cycle | |
| 14:18:03 | bauzas | we haven't yet branched RC1, so we could potentially merge it in time for RC1, but is that worth it ? | |
| 14:18:13 | bauzas | sorry, was in meeting... | |
| 14:18:39 | gibi | dansmith: before this cycle | |
| 14:18:44 | gibi | around Antelope | |
| 14:18:57 | bauzas | I really wanted to tag RC1 today, and mostly everything is done merged | |
| 14:19:08 | bauzas | even https://review.opendev.org/c/openstack/nova/+/942871/2 | |
| 14:19:33 | bauzas | so technically, I was about to propose a revision for nova RC1 https://review.opendev.org/c/openstack/releases/+/943941 | |
| 14:19:41 | dansmith | gibi: ack, so no new regression if we wait and backport | |
| 14:19:43 | gibi | bauzas: feel free to go and cut RC1. I can take care of this landing very early in F and backport it to E | |
| 14:19:51 | gibi | dansmith: yepp | |
| 14:19:54 | gibi | nothing new | |
| 14:19:58 | dansmith | bauzas: do eet | |
| 14:20:11 | bauzas | okay, then I'll set a new revision and let RC1 go | |
| 14:20:17 | gibi | cool | |
| 14:20:35 | bauzas | we're not that bad this cycle, we're only 4 days behind the original schedule :) | |
| 14:21:00 | gibi | :) | |
| 14:21:14 | gibi | the schedule was too early ;) we are ready when we are ready | |
| 14:21:32 | dansmith | that's not very agile :) | |
| 14:23:02 | bauzas | wait, we're upstream, we don't need to do agile here | |
| 14:23:11 | dansmith | \o/ | |
| 14:23:16 | bauzas | my world for a waterfall | |
| 14:24:38 | gibi | I think the we are ready when we are ready is pretty agile, we should have time based releases not content based, so we are ready whenever we can, and independently from this the release just happens automatically at any time. At least this is the theory :) | |
| 14:25:08 | dansmith | wouldn't that mean we'd have cut rc1 on the day regardless of what had merged? | |
| 14:26:05 | dansmith | punting your fix because it's not landed is agile/time-based, but my point was being 4 days behind schedule is not :) | |
| 14:28:18 | sean-k-mooney | we shoudl have cut RC1 last week yes | |
| 14:28:35 | sean-k-mooney | and upstream is agile not waterfall | |
| 14:28:41 | gibi | dansmith: nah you are right. I'm not advocating to wait with the release. I'm just joking around that time based releases only really time based if they are fully automatic (and fast), otherwise the release needs to wait for the humans to press buttons (i.e. review prelude etc) | |
| 14:28:42 | sean-k-mooney | we just have 6 month release | |
| 14:28:52 | sean-k-mooney | but its time based | |
| 14:29:05 | dansmith | gibi: yep | |
| 14:29:45 | sean-k-mooney | gibi: we propose the patches and auto merge them if the project teams dont -1 it | |
| 14:30:08 | gibi | maybe an LLM could keep a release notes prelude patch always up to date ready to merge for a sudden time based release | |
| 14:30:18 | sean-k-mooney | i joked about that | |
| 14:30:35 | sean-k-mooney | i was going to try and od that for watcher but then realised we didnt really have enough release notes to use | |
| 14:30:55 | sean-k-mooney | for nova it actully might be mossibale to get a first pass that you could word smit | |
| 14:31:34 | sean-k-mooney | we have enough source meatiral for it to possibly summerize | |
| 14:32:14 | dansmith | gibi: omg please don't | |
| 14:32:46 | gibi | I know I have dangerous jokes | |
| 14:33:01 | sean-k-mooney | bauzas: we have been particallary bad at doing time based release this cycle. its very much a low light for me | |
| 14:33:49 | sean-k-mooney | its somehting we need to try and avoid going forward | |
| 14:34:36 | dansmith | sean-k-mooney: what does that mean exactly? isn't this the first such thing this release? | |
| 14:35:18 | dansmith | I mean, assuming so that means we missed 100% so maybe that's your point, but.. :) | |
| 14:35:30 | sean-k-mooney | nope, the vfio-varitant dirver migraiton serise was not ready at feature freeze by enough that i dont think we should have granted it a FFE | |
| 14:36:07 | dansmith | oh so you mean s/release/deadline/ I guess | |
| 14:36:12 | sean-k-mooney | ya | |
| 14:36:22 | sean-k-mooney | we have been pretty flexible with all our deadlines this cycle | |
| 14:36:22 | dansmith | I mean, I don't think missing deadlines is new for us :) | |
| 14:37:01 | dansmith | oh I see you mean we weren't strict enough, I see | |
| 14:37:08 | dansmith | ++ for being stricter on that stuff, | |
| 14:37:09 | sean-k-mooney | no but we actully wanted to try an do better this cycle by haveing soft freezes ectra in december | |
| 14:37:28 | dansmith | although this conversation is in the context of not jamming something else into rc2 that isn't a regression, which is the right strict approach | |
| 14:37:41 | sean-k-mooney | so we intened to try and be stricter this cycle and proably were laxer then we have been for a good few cycles | |
| 14:37:45 | dansmith | we've been trying to do better on that since 2016 at least :D | |
| 14:38:17 | sean-k-mooney | im reivewing the repoducer patch at the moment by the way | |
| 14:38:37 | sean-k-mooney | so sort version we are going to back port this as normal after the release is done rather then rc2 right? | |
| 14:39:03 | sean-k-mooney | this being https://review.opendev.org/q/topic:%22bug/2098496%22 | |
| 14:39:40 | dansmith | yes | |
| 14:40:50 | sean-k-mooney | cool in that case ill continue with the review | |
| 14:41:06 | dansmith | stacking the +2s so we can +W when rc1 is cut would be nice | |
| 14:41:37 | sean-k-mooney | ya ill do that | |
| 14:42:29 | sean-k-mooney | my brain is currently parsing the repoducer logic. it looks reasonable but i have not completed that yet | |
| 15:00:30 | bauzas | Uggla: can you +1 https://review.opendev.org/c/openstack/releases/+/943941 ? | |
| 15:35:21 | gibi | sean-k-mooney: thanks for reviewing it | |
| 15:35:49 | sean-k-mooney | the repoducer looks fine im mostly done with the actual fix. | |
| 15:36:15 | sean-k-mooney | the one bit of context i dont have loaded is what exactly are we using requested_devs_per_pool_rp for | |
| 15:38:07 | sean-k-mooney | basicly the rest of the patch is pretty clear to me but im not entirly sure why https://review.opendev.org/c/openstack/nova/+/944277/7/nova/pci/stats.py#326 is needed | |
| 15:38:39 | sean-k-mooney | are you relying on count = requested_devs_per_pool_rp[pool['rp_uuid']] | |
| 15:38:48 | sean-k-mooney | to raise a key error if we try to calim another device | |
| 15:38:51 | gibi | sean-k-mooney: we are in a context of a single InstancePCIRequest. That is fufilled by a list of rp_uuis, the requested_devs_per_pool_rp is a counter (a dict) that tells how many devices needs to be allocated from a given rp_uuid in a given request | |
| 15:38:59 | sean-k-mooney | from the same pool if its alwreay exausted | |
| 15:39:47 | gibi | requested_devs_per_pool_rp[pool['rp_uuid']] is 0 if the rp_uuid is not in the requested_devs_per_pool_rp | |
| 15:40:01 | gibi | as it is a counter | |
| 15:40:28 | sean-k-mooney | ok | |
| 15:40:46 | sean-k-mooney | that sound reasonable | |