Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-18
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
16:10:20 bauzas #topic Release Planning
16:10:25 bauzas #link https://releases.openstack.org/epoxy/schedule.html
16:10:31 bauzas #link https://etherpad.opendev.org/p/nova-epoxy-rc-potential
16:10:41 bauzas as you can see, all of the open changes are now merged so...
16:10:45 bauzas #info RC1 tag https://review.opendev.org/c/openstack/releases/+/943941
16:10:52 bauzas should be merged today
16:11:48 bauzas which means that as soon as RC1 is tagged, epoxy branch is created and master becomes Flamingo :)
16:11:51 elodilles it's already on the gate ;)
16:12:09 Uggla \o/
16:12:15 bauzas which means we're already mostly in the Flamingo cycle now
16:12:20 bauzas #link https://releases.openstack.org/flamingo/schedule.html
16:12:25 bauzas #info Nova Flamingo deadlines will be discussed at the PTG.
16:14:00 bauzas we don't know yet the next deadlines for feature freeze and spec approvals, those will be discussed there
16:14:22 bauzas now, I'm passing the chair baton to Uggla :)
16:14:37 Uggla bauzas, thx
16:14:50 Uggla #topic Review priorities
16:15:07 Uggla #info Flamingo priorities will be discussed at the PTG.
16:15:31 Uggla #topic PTG planning
16:15:45 Uggla #info Next PTG will be held on Apr 7-11
16:15:58 Uggla #link https://etherpad.opendev.org/p/nova-2025.2-ptg
16:17:17 Uggla Thanks to fill the doc as soon as possible it will help to organize the PTG.
16:18:08 Uggla #topic Stable Branches
16:18:17 Uggla #info stable gates seem to be healthy
16:18:29 Uggla #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:18:47 bauzas Uggla: you usually can let elodilles speak :)
16:18:47 Uggla @elodilles, if you want to say something the floor is yours.

Earlier   Later