| bauzas | gibi: could you give a swing for the prelude ? https://review.opendev.org/c/openstack/nova/+/944713 | 08:12 |
|---|---|---|
| gibi | bauzas: sure | 08:12 |
| bauzas | ta | 08:13 |
| gibi | bauzas: could you quickly respin it to change vif mode to vif model? | 08:16 |
| gibi | I can proxy dansmith's +2 and land it afterwards | 08:16 |
| bauzas | gibi: sure | 08:17 |
| bauzas | we still are awaiting the QEMU version bump to land before we tag RC1 | 08:17 |
| bauzas | hopefully today we can branch :) | 08:18 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713 | 08:19 |
| gibi | bauzas: thanks, approved the prelude | 08:22 |
| bauzas | ty | 08:25 |
| bauzas | Uggla: I forgot that you're now the PTL in projects.yaml so I can't longer automatically have a PTL-Approved label in Gerrit, can you please +1 again https://review.opendev.org/c/openstack/releases/+/943801 ? | 08:27 |
| Uggla | Hello bauzas, done | 08:28 |
| bauzas | ty | 08:28 |
| bauzas | I'll start to modify the paperwork documentation for the new PTL :) | 08:28 |
| Uggla | cool | 08:29 |
| bauzas | once https://review.opendev.org/c/openstack/releases/+/943941, you'll be the new PTL :) | 08:29 |
| bauzas | Uggla: could you please +1 https://review.opendev.org/c/openstack/releases/+/943947 ? | 08:31 |
| Uggla | done as well | 08:32 |
| * Uggla afk for 10mn | 08:34 | |
| bauzas | fun, can't log into the openstack wiki | 08:44 |
| bauzas | anyone else ? | 08:44 |
| Uggla | bauzas, same for me apparently | 08:47 |
| bauzas | I left a ping in #openstack-infra | 08:47 |
| Uggla | bauzas, nop it is slow but ok | 08:48 |
| bauzas | we should move the wiki pages to the nova internal docs eventually, and just leave the meeting agenda as an etherpad | 08:48 |
| bauzas | no need for us to continue to run a wiki | 08:48 |
| 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 |
| bauzas | and many times it's either slow or broken | 08:49 |
| bauzas | gibi: same behaviour here | 08:49 |
| * bauzas will take the opportunity to move our main wikipage to the nova docs | 08:49 | |
| bauzas | I'm no longer a PTL but I have time :) | 08:50 |
| Uggla | login is working but it is very sloooow. | 08:51 |
| 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 |
| 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 |
| opendevreview | OpenStack Release Bot proposed openstack/placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944842 | 09:25 |
| opendevreview | Merged openstack/nova master: Add Epoxy prelude section https://review.opendev.org/c/openstack/nova/+/944713 | 10:06 |
| opendevreview | Merged openstack/nova master: Bump MIN_{LIBVIRT,QEMU} for "Epoxy" https://review.opendev.org/c/openstack/nova/+/942871 | 12:43 |
| frickler | \o/ | 12:44 |
| opendevreview | Merged openstack/placement stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944840 | 12:48 |
| 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 |
| opendevreview | Merged openstack/placement master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/placement/+/944842 | 12:59 |
| 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 |
| gibi | no need for an RC2 just for this | 13:57 |
| 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:04 |
| 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 |
| dansmith | I assume before this cycle | 14:05 |
| bauzas | we haven't yet branched RC1, so we could potentially merge it in time for RC1, but is that worth it ? | 14:18 |
| bauzas | sorry, was in meeting... | 14:18 |
| gibi | dansmith: before this cycle | 14:18 |
| gibi | around Antelope | 14:18 |
| bauzas | I really wanted to tag RC1 today, and mostly everything is done merged | 14:18 |
| bauzas | even https://review.opendev.org/c/openstack/nova/+/942871/2 | 14:19 |
| bauzas | so technically, I was about to propose a revision for nova RC1 https://review.opendev.org/c/openstack/releases/+/943941 | 14:19 |
| dansmith | gibi: ack, so no new regression if we wait and backport | 14:19 |
| 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 |
| gibi | dansmith: yepp | 14:19 |
| gibi | nothing new | 14:19 |
| dansmith | bauzas: do eet | 14:19 |
| bauzas | okay, then I'll set a new revision and let RC1 go | 14:20 |
| gibi | cool | 14:20 |
| bauzas | we're not that bad this cycle, we're only 4 days behind the original schedule :) | 14:20 |
| gibi | :) | 14:21 |
| gibi | the schedule was too early ;) we are ready when we are ready | 14:21 |
| dansmith | that's not very agile :) | 14:21 |
| bauzas | wait, we're upstream, we don't need to do agile here | 14:23 |
| dansmith | \o/ | 14:23 |
| bauzas | my world for a waterfall | 14:23 |
| 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:24 |
| dansmith | wouldn't that mean we'd have cut rc1 on the day regardless of what had merged? | 14:25 |
| 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:26 |
| sean-k-mooney | we shoudl have cut RC1 last week yes | 14:28 |
| sean-k-mooney | and upstream is agile not waterfall | 14:28 |
| 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 |
| sean-k-mooney | we just have 6 month release | 14:28 |
| sean-k-mooney | but its time based | 14:28 |
| dansmith | gibi: yep | 14:29 |
| sean-k-mooney | gibi: we propose the patches and auto merge them if the project teams dont -1 it | 14:29 |
| 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 |
| sean-k-mooney | i joked about that | 14:30 |
| 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 |
| sean-k-mooney | for nova it actully might be mossibale to get a first pass that you could word smit | 14:30 |
| sean-k-mooney | we have enough source meatiral for it to possibly summerize | 14:31 |
| dansmith | gibi: omg please don't | 14:32 |
| gibi | I know I have dangerous jokes | 14:32 |
| 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 |
| sean-k-mooney | its somehting we need to try and avoid going forward | 14:33 |
| dansmith | sean-k-mooney: what does that mean exactly? isn't this the first such thing this release? | 14:34 |
| dansmith | I mean, assuming so that means we missed 100% so maybe that's your point, but.. :) | 14:35 |
| 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:35 |
| dansmith | oh so you mean s/release/deadline/ I guess | 14:36 |
| sean-k-mooney | ya | 14:36 |
| dansmith | I mean, I don't think missing deadlines is new for us :) | 14:36 |
| sean-k-mooney | we have been pretty flexible with all our deadlines this cycle | 14:36 |
| dansmith | oh I see you mean we weren't strict enough, I see | 14:37 |
| dansmith | ++ for being stricter on that stuff, | 14:37 |
| sean-k-mooney | no but we actully wanted to try an do better this cycle by haveing soft freezes ectra in december | 14:37 |
| 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 |
| 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 |
| dansmith | we've been trying to do better on that since 2016 at least :D | 14:37 |
| sean-k-mooney | im reivewing the repoducer patch at the moment by the way | 14:38 |
| 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:38 |
| sean-k-mooney | this being https://review.opendev.org/q/topic:%22bug/2098496%22 | 14:39 |
| dansmith | yes | 14:39 |
| sean-k-mooney | cool in that case ill continue with the review | 14:40 |
| dansmith | stacking the +2s so we can +W when rc1 is cut would be nice | 14:41 |
| sean-k-mooney | ya ill do that | 14:41 |
| sean-k-mooney | my brain is currently parsing the repoducer logic. it looks reasonable but i have not completed that yet | 14:42 |
| bauzas | Uggla: can you +1 https://review.opendev.org/c/openstack/releases/+/943941 ? | 15:00 |
| gibi | sean-k-mooney: thanks for reviewing it | 15:35 |
| sean-k-mooney | the repoducer looks fine im mostly done with the actual fix. | 15:35 |
| 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:36 |
| 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 |
| sean-k-mooney | are you relying on count = requested_devs_per_pool_rp[pool['rp_uuid']] | 15:38 |
| sean-k-mooney | to raise a key error if we try to calim another device | 15:38 |
| 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 |
| sean-k-mooney | from the same pool if its alwreay exausted | 15:38 |
| 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:39 |
| gibi | as it is a counter | 15:40 |
| sean-k-mooney | ok | 15:40 |
| sean-k-mooney | that sound reasonable | 15:40 |
| gibi | counter is a nice data structure :) | 15:40 |
| sean-k-mooney | ill finish the review and read over that again | 15:40 |
| 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 |
| sean-k-mooney | so if that successed we can ignore that RP and move on | 15:43 |
| 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:44 |
| 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 |
| sean-k-mooney | but ok | 15:45 |
| sean-k-mooney | it does not hurt either | 15:45 |
| sean-k-mooney | requested_devs_per_pool_rp never leaves this funciton so poping it now or later does not really matter | 15:46 |
| 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:47 |
| gibi | yeah this is just super defensive right now | 15:48 |
| bauzas | #startmeeting nova | 16:00 |
| bauzas | #startmeeting nova | 16:01 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| opendevmeet | The meeting name has been set to 'nova' | 16:01 |
| bauzas | haha | 16:01 |
| * bauzas was wondering why it wasn't running | 16:02 | |
| gibi | o/ | 16:02 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:02 |
| * bauzas will add our next PTL for this meeting as a chair :) | 16:02 | |
| bauzas | #chair Uggla | 16:02 |
| opendevmeet | Current chairs: Uggla bauzas | 16:02 |
| elodilles | o/ | 16:02 |
| Uggla | o/ | 16:03 |
| bauzas | awaiting a few before starting | 16:04 |
| bauzas | #topic Bugs (stuck/critical) | 16:05 |
| bauzas | #info No Critical bug | 16:05 |
| 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 |
| bauzas | anything about bugs ? | 16:05 |
| masahito | hello o/ | 16:06 |
| bauzas | #topic Gate status | 16:07 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:07 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:07 |
| 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 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:07 |
| bauzas | #info Please try to provide meaningful comment when you recheck | 16:07 |
| bauzas | anything about the gate ? | 16:08 |
| bauzas | if not, moving on | 16:10 |
| bauzas | #topic Release Planning | 16:10 |
| bauzas | #link https://releases.openstack.org/epoxy/schedule.html | 16:10 |
| bauzas | #link https://etherpad.opendev.org/p/nova-epoxy-rc-potential | 16:10 |
| bauzas | as you can see, all of the open changes are now merged so... | 16:10 |
| bauzas | #info RC1 tag https://review.opendev.org/c/openstack/releases/+/943941 | 16:10 |
| bauzas | should be merged today | 16:10 |
| bauzas | which means that as soon as RC1 is tagged, epoxy branch is created and master becomes Flamingo :) | 16:11 |
| elodilles | it's already on the gate ;) | 16:11 |
| Uggla | \o/ | 16:12 |
| bauzas | which means we're already mostly in the Flamingo cycle now | 16:12 |
| bauzas | #link https://releases.openstack.org/flamingo/schedule.html | 16:12 |
| bauzas | #info Nova Flamingo deadlines will be discussed at the PTG. | 16:12 |
| bauzas | we don't know yet the next deadlines for feature freeze and spec approvals, those will be discussed there | 16:14 |
| bauzas | now, I'm passing the chair baton to Uggla :) | 16:14 |
| Uggla | bauzas, thx | 16:14 |
| Uggla | #topic Review priorities | 16:14 |
| Uggla | #info Flamingo priorities will be discussed at the PTG. | 16:15 |
| Uggla | #topic PTG planning | 16:15 |
| Uggla | #info Next PTG will be held on Apr 7-11 | 16:15 |
| Uggla | #link https://etherpad.opendev.org/p/nova-2025.2-ptg | 16:15 |
| Uggla | Thanks to fill the doc as soon as possible it will help to organize the PTG. | 16:17 |
| Uggla | #topic Stable Branches | 16:18 |
| Uggla | #info stable gates seem to be healthy | 16:18 |
| Uggla | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:18 |
| Uggla | @elodilles, if you want to say something the floor is yours. | 16:18 |
| bauzas | Uggla: you usually can let elodilles speak :) | 16:18 |
| elodilles | thanks bauzas Uggla :) | 16:19 |
| elodilles | nothing to say ;) | 16:19 |
| elodilles | stable gates were quiet this week :) | 16:19 |
| elodilles | i guess due to RC1 rush | 16:19 |
| sean-k-mooney | we probaly will want to do some stable release in the next week or two | 16:19 |
| sean-k-mooney | but obvioulsy finishing 2025.1 is the higher priority | 16:19 |
| elodilles | sean-k-mooney: sure, we can do that | 16:20 |
| elodilles | indeed, 2025.1 is the top prio right now | 16:20 |
| elodilles | and for the coming 2 weeks ;) | 16:20 |
| sean-k-mooney | once that done its good to look at the stable branch and see if any have patches that should be put in a release | 16:20 |
| elodilles | especially as stable/2023.2 (bobcat) will move to End of Life | 16:20 |
| sean-k-mooney | yep | 16:20 |
| sean-k-mooney | do we have a deadlien for that? | 16:21 |
| elodilles | and will be deleted ~1 month after 2025.1 Epoxy release | 16:21 |
| elodilles | sean-k-mooney: ^^^ that | 16:21 |
| sean-k-mooney | :) | 16:21 |
| elodilles | and we should not leave the release at the deadline | 16:21 |
| elodilles | in case we deliver some regression we cannot fix that anymore | 16:22 |
| sean-k-mooney | right we should proably try to do a stable review spritn in like 3 weeks | 16:22 |
| elodilles | which is unlikely, but let's not leave a chance for that ;) | 16:22 |
| elodilles | sean-k-mooney: +1 | 16:22 |
| elodilles | so yeah, that's all about stable i think | 16:23 |
| Uggla | thx @elodilles, so moving on. | 16:23 |
| * gibi has a lot of pending backports :) | 16:23 | |
| elodilles | and some of them are waiting for a 2nd +2 if i'm not mistaken o:) | 16:24 |
| gibi | :) | 16:25 |
| Uggla | probably some FUP from my side too... | 16:25 |
| Uggla | ok next topic | 16:26 |
| Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | 16:26 |
| Uggla | #info Investigating another regression on the network side | 16:26 |
| fwiesel | Hi, no update from my side. I am currently on sick leave, so no probably no updates next week either. | 16:26 |
| Uggla | fwiesel, if you want to say something. that's your turn. | 16:26 |
| sean-k-mooney | fwiesel: no worreis, you proably shoudl go rest so instead of being on irc | 16:26 |
| sean-k-mooney | fwiesel: dont feel pressuered to be here if your unwell | 16:27 |
| opendevreview | OpenStack Release Bot proposed openstack/nova stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/nova/+/944888 | 16:27 |
| opendevreview | OpenStack Release Bot proposed openstack/nova stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/nova/+/944889 | 16:27 |
| opendevreview | OpenStack Release Bot proposed openstack/nova master: Update master for stable/2025.1 https://review.opendev.org/c/openstack/nova/+/944890 | 16:27 |
| fwiesel | No, no problem. | 16:27 |
| fwiesel | I take it slowly. So, that's from my side. | 16:28 |
| fwiesel | Back to you Uggla. | 16:28 |
| Uggla | fwiesel, take it easy, I wish you a prompt recovery. | 16:29 |
| Uggla | #topic Open discussion | 16:29 |
| ishanwar[m] | #topic Bug #2027156 Low hanging fruit | 16:30 |
| ishanwar[m] | https://bugs.launchpad.net/nova/+bug/2027156 | 16:30 |
| Uggla | I know @bauzas wants to discuss about being release liaison. I think this is to make the next release point easier. | 16:30 |
| bauzas | oh, it was just because I miss my PTL-Approval gerrit label :D | 16:31 |
| bauzas | and I want to know if anyone has concerns with me continuing to do release liaison ? | 16:31 |
| gibi | having redundancy in our staffing to push a release make sense to me | 16:31 |
| Uggla | no pb on my side. | 16:32 |
| sean-k-mooney | not really, we are allowed to chnage that at any time during the release os we can just propsoe the patch | 16:32 |
| elodilles | +2 from me too | 16:32 |
| sean-k-mooney | and dicuss it ther | 16:32 |
| sean-k-mooney | ishanwar[m]: we will loop back ot you next | 16:32 |
| bauzas | cool cool, then I'll propose myself :) | 16:32 |
| bauzas | that was short and quick :) | 16:32 |
| ishanwar[m] | sean-k-mooney: sure | 16:32 |
| Uggla | so I think we can discuss ishanwar[m] topic. | 16:33 |
| Uggla | ishanwar[m], please go ahead. | 16:33 |
| ishanwar[m] | I wanted to have a discussion on https://bugs.launchpad.net/nova/+bug/2027156 | 16:34 |
| dansmith | that doesn't look like low-hanging fruit to me :) | 16:34 |
| dansmith | is there a review up? | 16:34 |
| ishanwar[m] | no I am still working on it | 16:35 |
| dansmith | okay, if the quota api is not something that we can guarantee is available, then we have to have all the code we have today in nova, plus new code to use the api if present, right? | 16:35 |
| ishanwar[m] | wanted to discuss if I understood it correctly,... (full message at <https://matrix.org/oftc/media/v1/media/download/AZZiNbMs1GZbZLUOwiWvG2I_Dg7_qJ2sHecbqrafIK6K_9GcmEgBnqAHwcu-vfVKIV_6lx6PmdvT59UIS_UEVuBCeV8jVjWgAG1hdHJpeC5vcmcvekZxaUt3b3hkYnpmanJ2dkZqQ2lESFJY>) | 16:35 |
| ishanwar[m] | the bug mentions https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2654 | 16:36 |
| ishanwar[m] | as the candidate for change but i am not sure, if we are counting in ports in that function. | 16:36 |
| ishanwar[m] | am i right ? | 16:36 |
| sean-k-mooney | so part of the problem is the orginal bug report does not use permalinks | 16:37 |
| dansmith | ishanwar[m]: that bug was filed by a neutron person so I suspect we won't be able to answer your question authoritatively without really digging in | 16:37 |
| sean-k-mooney | so they dont nessiarly link to the correct code any more | 16:37 |
| sean-k-mooney | ishanwar[m]: you are correct that validate_networks does use the quota api already https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2714 | 16:38 |
| sean-k-mooney | i guess the real quetion is do we use that in all places we do quota checks | 16:38 |
| sean-k-mooney | this was orginaly reported downstream for trian | 16:39 |
| sean-k-mooney | so its very possibel that htis was fixed already in master | 16:39 |
| ishanwar[m] | Yes correct, but it's still listing all ports to count them, rather than using show_quota_details, right ? | 16:39 |
| sean-k-mooney | we do a port list in get_requested_resource_for_instance | 16:40 |
| sean-k-mooney | but that not listing all ports for the porject | 16:40 |
| ishanwar[m] | sean-k-mooney: not sure if this is fixed elsewhere, I was only able to find one usage of len(ports) | 16:40 |
| sean-k-mooney | that is geting port for the current instnace wihch is fine | 16:40 |
| ishanwar[m] | sean-k-mooney: yes | 16:41 |
| dansmith | we fetch the quota, but we do our own usage calculation it looks like | 16:41 |
| sean-k-mooney | oh its this second call https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2721 | 16:41 |
| dansmith | we don't ask if the quota is exceeded, we ask what the quota is and then sum the current+new and see if it's over | 16:41 |
| sean-k-mooney | that ^ is the line that shoudl be updated | 16:41 |
| ishanwar[m] | dansmith: yes in https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2714 | 16:41 |
| ishanwar[m] | we are still counting all the ports | 16:41 |
| sean-k-mooney | ishanwar[m]: so the bug is this | 16:42 |
| sean-k-mooney | there is another extention that gives use both the quota and the uses cont in one call | 16:42 |
| ishanwar[m] | yes correct, i think we can use show_quota_details here right ? | 16:42 |
| ishanwar[m] | sean-k-mooney: which one ? | 16:42 |
| sean-k-mooney | so instead of getting all the ports for the curent project just to count them we can use show_quota_details | 16:42 |
| sean-k-mooney | ishanwar[m]: so the performace bug is still there | 16:43 |
| dansmith | ...if available | 16:43 |
| sean-k-mooney | on this line https://github.com/openstack/nova/blob/6042300453411133652dd8d3b789f5057a084075/nova/network/neutron.py#L2721 | 16:43 |
| sean-k-mooney | but ya as dan impleid we have to fall back if the extension is not there | 16:43 |
| dansmith | it's also racy either way, which is unfortunate | 16:43 |
| ishanwar[m] | sean-k-mooney: correct I agree | 16:43 |
| ishanwar[m] | so we can use a try catch mech to check if the extension is available or not | 16:43 |
| ishanwar[m] | dansmith: oh, how is that ? | 16:44 |
| dansmith | ishanwar[m]: if we calculate the quota, allow to proceed and other things in parallel use more quota, we'll be wrong and run out of quota while actually creating the ports | 16:44 |
| dansmith | since we already need to handle that, why check quota at all? Just try to create the ports and roll back if you run out.. I guess maybe to provide a quick answer via API, but it will never be guaranteed | 16:45 |
| sean-k-mooney | well we do prot creation on the comptues | 16:45 |
| sean-k-mooney | so we do the api check to fail fast if we are already at quota | 16:45 |
| dansmith | this can say "definitely not enough quota" but it can't say "definitely enough" | 16:45 |
| dansmith | right | 16:45 |
| ishanwar[m] | Not sure I understood 😓 | 16:46 |
| sean-k-mooney | ishanwar[m]: so to answer your question, the bug is still there adn we can still optimize this call to neturon | 16:46 |
| dansmith | there's a long window between checking quota and consuming it | 16:46 |
| sean-k-mooney | but we need to fallback if the extion is not there to the current logic. | 16:46 |
| ishanwar[m] | I have another question, i am running the openstack nova dev env on devstack. is there a way how I can test my changes for this bug, sorry I am new to this ? | 16:47 |
| dansmith | with devstack yes, make your changes and test manually, but this will also need unit/functional tests in the patch | 16:48 |
| sean-k-mooney | ishanwar[m]: to do ^ you just modify the code and do "systemctl restart devstack@n-*" | 16:49 |
| sean-k-mooney | i.e. modify the code in /opt/stack/nova | 16:49 |
| sean-k-mooney | i generally do it slightly idffently by have a copy in another location and pip install that into the devstack virutal env but you can basiclly just modify the code and restart the affected services. in thsi case devtack@n-api is the nova api | 16:50 |
| Uggla | ishanwar[m], also finding something similar to the bug in gerrit can be a good example to know what the patch should have in terms of unit/fn tests. | 16:50 |
| ishanwar[m] | this restarts all nova services right ? Shouldn't we check just one, in general what process do you follow ? Do you add breakpoints etc for testing things out ? | 16:51 |
| sean-k-mooney | you can look at the function above https://github.com/openstack/nova/blob/6042300453411133652dd8d3b789f5057a084075/nova/network/neutron.py#L2672-L2693 | 16:51 |
| sean-k-mooney | it does an if/else on if the extenion is supproted | 16:51 |
| sean-k-mooney | you can look at howe has_extended_resource_request_extension is implemnted to test for the quta details one | 16:52 |
| ishanwar[m] | sean-k-mooney: yes understood, makes sense . | 16:52 |
| sean-k-mooney | ishanwar[m]: so you cant really run nova under a debugger | 16:52 |
| sean-k-mooney | its posssible but hard | 16:52 |
| sean-k-mooney | so generally we add debug logs | 16:52 |
| ishanwar[m] | sean-k-mooney: yeah I can implement ifelse for this | 16:52 |
| sean-k-mooney | that useful for production as well as in production we will generally only have logs aviable | 16:53 |
| ishanwar[m] | sean-k-mooney: okay I see. | 16:53 |
| ishanwar[m] | sean-k-mooney: hmm i see. So from what I understood, add logs, for testing, restart the n-api service. Use openstack command line for testing, correct ? | 16:54 |
| sean-k-mooney | initally but then you will need to add unit test for each branch | 16:55 |
| sean-k-mooney | so mocking the has_extenion_* function for true and false | 16:55 |
| ishanwar[m] | Can you share an example ? | 16:55 |
| sean-k-mooney | and assert list_port or quota_detials is called approreatly | 16:55 |
| sean-k-mooney | yep we can proably do that perhaps after the meeting | 16:56 |
| sean-k-mooney | incase there are any other topics | 16:56 |
| ishanwar[m] | sure, thanks sean-k-mooney dansmith Uggla | 16:56 |
| ishanwar[m] | i think we can close this discussion | 16:56 |
| ishanwar[m] | back to you Uggla | 16:56 |
| Uggla | thx @ishanwar[m] | 16:56 |
| Uggla | any other topic ? | 16:57 |
| Uggla | looks we can close the meeting | 16:58 |
| Uggla | 3 | 16:58 |
| bauzas | shoot :) | 16:58 |
| Uggla | 2 | 16:58 |
| dansmith | blastoff | 16:58 |
| Uggla | thanks all | 16:59 |
| Uggla | #endmeeting | 16:59 |
| opendevmeet | Meeting ended Tue Mar 18 16:59:10 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-18-16.01.html | 16:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-18-16.01.txt | 16:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-03-18-16.01.log.html | 16:59 |
| bauzas | heh, that worked well :) | 16:59 |
| gibi | bauzas, Uggla thanks | 16:59 |
| bauzas | thanks Uggla | 16:59 |
| elodilles | thanks Uggla bauzas o/ | 16:59 |
| masahito | thank you, Uggla and bauzas | 16:59 |
| sean-k-mooney | ishanwar[m]: so if you look at https://github.com/openstack/nova/commit/191bdf2069086493be2a2e0351afa7f3efad7099#diff-de8fba9a58a07803b3d46cfb1f58d1b89e7cc63684f02c30297e6bdabffe870eR4373 you will see some exampel fo what the unit test should look like | 16:59 |
| Uggla | bauzas, thanks | 16:59 |
| ishanwar[m] | Hmm I can see mock objects sean-k-mooney , I'll have a detailed look | 17:01 |
| ishanwar[m] | thanks | 17:01 |
| sean-k-mooney | yep we mock the calls to neutron and assert they are called or not called depending on what should happen | 17:01 |
| sean-k-mooney | ishanwar[m]: you should be able to find an exeitin tst for the validate_networks funciton | 17:02 |
| sean-k-mooney | make a copy and test that it calls or does not call list_prots by mocking teh function that will check for the extension | 17:02 |
| ishanwar[m] | aah i see, right, I think can use that for checking whether the function is available. | 17:07 |
| cardoe | Will I be able to sneak https://review.opendev.org/c/openstack/nova/+/942019 into 2025.1 or will that have to be a backport? | 18:02 |
| sean-k-mooney | cardoe: unless its a regression introduced in 2025.1 it will be a a post release backport | 18:03 |
| cardoe | it's a regression introduced in 2024.1 | 18:03 |
| sean-k-mooney | cardoe: ah the loggign fix | 18:03 |
| sean-k-mooney | ya so that wont qualify for rc2 | 18:03 |
| sean-k-mooney | and we just? curt the stable branch form rc1 | 18:04 |
| sean-k-mooney | so it can merge on master but cant be backported until after 2025.1 is released | 18:04 |
| cardoe | sounds good. | 18:04 |
| opendevreview | sean mooney proposed openstack/nova master: Force api to exit if exceptions are uncaught https://review.opendev.org/c/openstack/nova/+/944933 | 18:15 |
| opendevreview | Merged openstack/nova stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/nova/+/944888 | 18:37 |
| opendevreview | Merged openstack/nova stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/nova/+/944889 | 18:37 |
| dansmith | bauzas: Uggla are we good to go on master based on ^ ? | 18:42 |
| dansmith | if so I'll +W gibi's fix series | 18:42 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!