| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-18 | |||
| 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 | dansmith | I mean, I don't think missing deadlines is new for us :) | |
| 14:36:22 | sean-k-mooney | we have been pretty flexible with all our deadlines this cycle | |
| 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 | |
| 15:40:56 | gibi | counter is a nice data structure :) | |
| 15:40:57 | sean-k-mooney | ill finish the review and read over that again | |
| 15:43:41 | sean-k-mooney | ok so in consume we just pop it form the set we need to allcoate because self._allocate_devs shoudl allcoate "count" device regardelss of how many we ask for | |
| 15:43:54 | sean-k-mooney | so if that successed we can ignore that RP and move on | |
| 15:44:49 | gibi | yeah basically if we allocated all for this rp we don't need to keep the rp in the counter as we never want to allocate for this rp again for this request | |
| 15:45:28 | sean-k-mooney | im not sure that actully heps because we are looping over the pools so we should never have 2 pools with the same rp_uuid | |
| 15:45:37 | sean-k-mooney | but ok | |
| 15:45:44 | sean-k-mooney | it does not hurt either | |
| 15:46:04 | sean-k-mooney | requested_devs_per_pool_rp never leaves this funciton so poping it now or later does not really matter | |
| 15:47:51 | sean-k-mooney | its proably slightly slower to do it this way then droping the entire collection of counters the end of the function but only slightly | |
| 15:48:35 | gibi | yeah this is just super defensive right now | |
| 16:00:59 | bauzas | #startmeeting nova | |
| 16:01:51 | bauzas | #startmeeting nova | |
| 16:01:51 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:01:51 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:01:51 | opendevmeet | Meeting started Tue Mar 18 16:01:51 2025 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:01:54 | bauzas | haha | |
| 16:02:24 | gibi | o/ | |
| 16:02:30 | bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | |
| 16:02:52 | bauzas | #chair Uggla | |
| 16:02:52 | opendevmeet | Current chairs: Uggla bauzas | |
| 16:02:56 | elodilles | o/ | |
| 16:03:00 | Uggla | o/ | |
| 16:04:09 | bauzas | awaiting a few before starting | |
| 16:05:29 | bauzas | #topic Bugs (stuck/critical) | |
| 16:05:38 | bauzas | #info No Critical bug | |
| 16:05:43 | bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:05:47 | bauzas | anything about bugs ? | |
| 16:06:25 | masahito | hello o/ | |
| 16:07:11 | bauzas | #topic Gate status | |
| 16:07:16 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:07:22 | bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | |
| 16:07:29 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | |
| 16:07:35 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:07:39 | bauzas | #info Please try to provide meaningful comment when you recheck | |
| 16:08:44 | bauzas | anything about the gate ? | |
| 16:10:10 | bauzas | if not, moving on | |