Tuesday, 2025-10-07

*** bauzas9 is now known as bauzas00:23
*** mhen_ is now known as mhen02:03
jlejeune1gibi: hello, what do you think about: https://review.opendev.org/c/openstack/nova/+/963156 ? first requirement to fix bug 208513506:59
*** jlejeune1 is now known as jlejeune07:00
sthoffmann[m]Hi, I wrote a RFE for how to wait for ovn-controller at live-migration https://bugs.launchpad.net/neutron/+bug/2069718. I included some feedback to the POC changes I created for that. Can you approve from nova side, that the RFE/blueprint is ok?08:19
opendevreviewBalazs Gibizer proposed openstack/placement master: Prune a_c search space by invalid prefixes  https://review.opendev.org/c/openstack/placement/+/96277608:50
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline _consolidate_allocation_requests  https://review.opendev.org/c/openstack/placement/+/96305208:50
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline exceeds_capacity  https://review.opendev.org/c/openstack/placement/+/96305308:50
opendevreviewBalazs Gibizer proposed openstack/placement master: Prune a_c search space by invalid prefixes  https://review.opendev.org/c/openstack/placement/+/96277609:58
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline _consolidate_allocation_requests  https://review.opendev.org/c/openstack/placement/+/96305209:58
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline exceeds_capacity  https://review.opendev.org/c/openstack/placement/+/96305309:58
opendevreviewBalazs Gibizer proposed openstack/placement master: Prune a_c search space by invalid prefixes  https://review.opendev.org/c/openstack/placement/+/96277610:08
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline _consolidate_allocation_requests  https://review.opendev.org/c/openstack/placement/+/96305210:08
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline exceeds_capacity  https://review.opendev.org/c/openstack/placement/+/96305310:08
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline _consolidate_allocation_requests  https://review.opendev.org/c/openstack/placement/+/96305210:23
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline exceeds_capacity  https://review.opendev.org/c/openstack/placement/+/96305310:23
priteauHi Nova team! I have a trivial doc fix that has been open for a while: https://review.opendev.org/c/openstack/nova/+/95556611:51
gibipriteau: thanks. fast approved it12:00
priteauthanks!12:03
opendevreviewMerged openstack/nova master: doc: Fix typo in nova-manage command  https://review.opendev.org/c/openstack/nova/+/95556612:11
opendevreviewBalazs Gibizer proposed openstack/placement master: Prune a_c search space by invalid prefixes  https://review.opendev.org/c/openstack/placement/+/96277612:14
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline _consolidate_allocation_requests  https://review.opendev.org/c/openstack/placement/+/96305212:14
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline exceeds_capacity  https://review.opendev.org/c/openstack/placement/+/96305312:14
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline _consolidate_allocation_requests  https://review.opendev.org/c/openstack/placement/+/96305212:34
opendevreviewBalazs Gibizer proposed openstack/placement master: Inline _consolidate_allocation_requests  https://review.opendev.org/c/openstack/placement/+/96305212:34
gibidansmith: sean-k-mooney: ^^ the prune https://review.opendev.org/c/openstack/placement/+/962776 and the inlining of consolidation https://review.opendev.org/c/openstack/placement/+/963052 patches are ready for review from my perspective. I'm abandoning the 3rd patch https://review.opendev.org/c/openstack/placement/+/963053 as it does not significantly help12:36
gibiI will add a 3rd patch on top with a reno12:39
opendevreviewKamil Sambor proposed openstack/nova master: [hacking] Improve N373 to catch also other primitives  https://review.opendev.org/c/openstack/nova/+/95840812:58
opendevreviewBalazs Gibizer proposed openstack/placement master: Release notes for bug/2126751  https://review.opendev.org/c/openstack/placement/+/96327513:01
sean-k-mooneygibi:  ack i see you chosse not to factor out the logic into a helper. that is fine we can mark that restolved. i think the fact that you are not just purly inline and are integrating it into the algorthim while graduclaly buildign the candiates is called out enough in the commit13:02
sean-k-mooneyill try and make some time later to treview them13:02
sean-k-mooneygibi: nit: wyou have whitespace issues in teh relese note patch13:02
opendevreviewBalazs Gibizer proposed openstack/nova master: DNM: test with placement fix  https://review.opendev.org/c/openstack/nova/+/96303513:03
opendevreviewBalazs Gibizer proposed openstack/nova master: DNM:Test with optimize_for_wide_provider_trees  https://review.opendev.org/c/openstack/nova/+/96303613:03
gibisean-k-mooney: ack I will fix them13:11
opendevreviewBalazs Gibizer proposed openstack/nova master: [doc]PCI in Placement tuning  https://review.opendev.org/c/openstack/nova/+/96328113:16
dansmithgibi: what was the fix for not generating the extra duplicate matches?13:52
opendevreviewBalazs Gibizer proposed openstack/nova-specs master: Placement child resource provider usage in allocation-candidates  https://review.opendev.org/c/openstack/nova-specs/+/93807013:54
dansmithoh was it the deepcopy in the test itself maybe?13:55
opendevreviewBalazs Gibizer proposed openstack/nova-specs master: Placement child resource provider usage in allocation-candidates  https://review.opendev.org/c/openstack/nova-specs/+/93807013:55
gibidansmith: I needed to copy the call args in the test as they are lists that are mutated between calls and the mock only stores the reference to the list13:56
dansmithack, so the code was doing the right thing, the test was just wrong.. I was hoping there was more optimization coming from the fix for that :)13:56
gibime too13:56
gibi:)13:56
gibisean-k-mooney: dansmith: as you see the links above I pushed a nova doc change to link to the placement optimizations in the PCI in Placement doc. And I updated our backlog spec about the general allocation candidated explosioin problem with the new learning about the invalid candidates 13:58
dansmith++13:58
dansmithgibi: some comments and a couple questions on the latest rev14:01
gibiOK. I will check 14:01
gibithanks14:01
dansmithgibi: apologies for going grammar police on it, but this is hard stuff to understand and having the english all correct definitely helps me when I'm trying to understand14:02
gibino worries. I do need help explaning this clearly for the reader14:16
dansmithI think I'm pretty happy with the implementation now though.. feeling more comfortable for sure14:20
*** NeilHanlon_ is now known as NeilHanlon15:06
UgglaNova meeting in ~50mn15:08
melwittdansmith: I'm not sure if enable_service barbican would work. I have been using "enable_plugin barbican https://opendev.org/openstack/barbican"15:10
dansmithmelwitt: ack15:11
dansmiththanks15:11
melwittdansmith: something to know about configuring barbican (which will be after everything is stacked afaik) is that the canned config will require you to add the "creator" role for any user that will need to create secrets. so for this it will be the user you will use to create VMs and also the nova service user. alternatively,15:14
dansmithorly15:14
melwittif you configure enforce_new_defaults = true and enforce_scope = true you will not need the "creator" role. that's what I do bc I don't like doing role assignments if I can avoid it15:14
dansmithin barbican's config I assume?15:15
melwittyes15:15
melwittin case it's helpful, this is the zuul job config I use for the proposed tempest tests I have proposed https://review.opendev.org/c/openstack/nova/+/957477/19/.zuul.yaml it could help to just see what sort of settings there are. you will not need to do all of that obviously like things about tempest15:18
dansmithyeah cool, thanks,15:22
opendevreviewJohn Garbutt proposed openstack/nova master: Fix Ironic Rebuild with API >=2.93  https://review.opendev.org/c/openstack/nova/+/96329815:37
UgglaNova meeting in ~15mn15:45
opendevreviewJohn Garbutt proposed openstack/nova master: Fix ironic rebuild with API >=2.93  https://review.opendev.org/c/openstack/nova/+/96329815:55
opendevreviewJohn Garbutt proposed openstack/nova master: Fix ironic rebuild with API >=2.93  https://review.opendev.org/c/openstack/nova/+/96329815:57
Uggla#startmeeting nova16:00
opendevmeetMeeting started Tue Oct  7 16:00:58 2025 UTC and is due to finish in 60 minutes.  The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'nova'16:00
UgglaHello everyone16:01
fwieselo/16:01
kgubeo/16:02
Ugglaawaiting others to join.16:02
elodilleso/16:02
bauzaso/16:02
dansmitho/16:02
UgglaLet's start16:04
Uggla#topic Bugs (stuck/critical) 16:04
Uggla#info No Critical bug16:04
Uggla#topic Gate status16:04
Uggla#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:04
Uggla#link https://etherpad.opendev.org/p/nova-ci-failures-minimal16:04
Uggla#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 status16:04
Uggla#info Please look at the gate failures and file a bug report with the gate-failure tag.16:04
Uggla#info Please try to provide a meaningful comment when you recheck16:05
opendevreviewKonrad Gube proposed openstack/nova-specs master: Re-propose using extend volume completion action for 2026.1  https://review.opendev.org/c/openstack/nova-specs/+/94950416:05
UgglaI haven't seen anything special regarding gate.16:05
UgglaDoes someone want to report something.16:05
UgglaI guess gibi is still monitoring nova-tox-py312-threading16:06
bauzasyup16:07
UgglaPlease notify gibi for any strange behavior on this job.16:07
UgglaSkipping next point because gmann is on PTO.16:08
Uggla#topic Release Planning16:08
Uggla#link https://releases.openstack.org/gazpacho/schedule.html16:08
Uggla^ reminder, we will discuss timeline at the ptg.16:09
Uggla#info Flamingo released last week. \o/16:09
Uggla#info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg16:09
Uggla#info Please add the topics you would like to discuss in the above document.16:09
Uggla#info PTG meetings (to be confirmed) will happen room grizzly 15:00UTC ->17:00UTC from Tuesday to Friday16:10
UgglaNext week, openinfra summit will happen16:10
UgglaAt least bauzas, and I will be present.16:11
bauzasyup16:11
* elodilles , too16:11
UgglavPTG is in 3 weeks from now.16:11
Ugglaelodilles cool !16:11
elodillessee you there!16:12
Ugglasure.16:12
bauzasgood time for a beer :)16:13
UgglaNote: open infra summit is ~1h by train from city center.16:13
elodilles+116:13
Ugglamoving on16:14
Uggla#topic OpenAPI 16:14
Uggla#link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned16:14
Uggla#info still 28 remaining atm.16:14
UgglaI hope we will be able to merge the remaining ones beginning of the cycle.16:15
Uggla#topic Stable Branches16:15
* Uggla passing the mic to elodilles16:15
elodillesthanks o/16:15
elodillesi'm not aware of any stable gate issue16:15
elodillesthis is a calm period, now that 2025.1 Flamingo is released last week16:16
elodilles#info stable branches (stable/2025.* and stable/2024.*) seem to be in OK state16:16
elodillesthat's all from me, back to you Uggla 16:16
Ugglagood if it is calm16:17
elodillesyepp :)16:17
Uggla#topic vmwareapi 3rd-party CI efforts Highlights16:17
fwieselNo updates from my side.16:17
Ugglafwiesel, thx16:18
Ugglagibi seems not available.16:18
gibisorry16:19
gibino news from me16:19
Ugglagibi, that's perfectly ok.16:19
gibi(busy with other bugfixes)16:19
Ugglagibi, I know. Important fixes.16:20
Uggla#topic Open discussion16:20
Uggla(Uggla) Pool for the new schedule of upstream meeting: https://framadate.org/ao12zK6wR3K3nfbF16:20
Uggla#linkAnnonce : https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/H5PBFZJ4X3TSGSC4YF6E4WTV43CBOVS6/16:20
Ugglaplease vote ^16:21
bauzasI saw it but I need to calculate with all the existing meetings, it will take time before replying :(16:22
UgglaBy the way as mentionned in the mail, we will have to adjust it again with the daylight change.16:22
elodillesUggla: which one, the US or the EU daylight change?16:23
elodilles(or other, that i'm not aware of...)16:24
gibihm the voting options are in UTC that is not observing daylight saving16:25
Ugglaelodilles, I think the EU. Otherwise most of us will have a conflict.  16:25
elodilles(end of DST in EU: Oct 26, 2025; end of DST in US: Nov 2, 2025; if I'm not mistaken)16:26
elodillesUggla: ACK16:26
Ugglaelodilles, that also depends the day we will choose.16:27
gibibut if we want to observe daylight saving then the option cannot be UTC as UTC is not affected by daylight saving16:27
* gibi is confused16:27
Ugglagibi, the tool upstream only accept UTC.16:27
elodilles(and that is more 'readable' for every participants)16:28
elodilles(at least that is a 'common' timezone everyone understands)16:28
gibiwhich is fine by me. But you are talking about changing during dayligh saving and that does not make sense to me as UTC is not affected16:28
gibie.g. if I vote 16:00 UTC, then it is always 16:00 UTC regardless of where am I on earth and what part of the year we are16:30
gibido you suggest we will update the 16:00 UTC to some other time when we move to daylight saving?16:30
Ugglagibi, after the daylight our meeting which is usually at 18h00 CET, will move to 17h00 CET and will conflict with one internal.  16:30
Uggla"do you suggest we will update the 16:00 UTC to some other time when we move to daylight saving?" yes absolutelly16:30
gibiwhy? :)16:31
UgglaWe will probably have to move from 16:00 UTC to 17:00 UTC.16:31
gibido you want to keep the timing constant in EU?16:32
gibithat will create 4 changes of time in US16:32
gibiprobably not something the US folks will like16:32
gibiif we stick to UTC then both EU and US has 2 changes per year to adapt to16:32
* Uggla just want to avoid meeting conflicts16:33
Ugglas/want/wants/16:33
UgglaBut having internal ones in UTC would help.16:34
bauzashonestly, there is no solution here, let's continue with UTC and just signal when we have conflicts after DST 16:34
gibiI think sticking to UTC is the least confusing for the community. Moving twice a year to keep the EU time constant is an optimization for EU but a complication for U16:35
gibiI have to drop now but I will read back...16:35
bauzasthat's why it takes time to look at the framedate one given I need to look at both of the times16:35
Ugglabauzas, yep16:36
UgglaAnyway, something else to discuss ?16:36
kgubeI just wanted to ask, is there a cross-project session planned with Cinder at the PTG?16:37
Ugglakgube, I have not discussed with cinder yep, but probably yes.16:38
kgubealright, thanks!16:38
UgglaIf you want to have a cross discussion with cinder, please write that in our doc, and I'll arrange with Cinder folks to find a timeslot.16:39
kgubeThe NetApp/NFS online resize topic might fit well there, I have added a comment16:39
Ugglaok, please also add your name around?16:40
UgglaAnything else ?16:40
bauzas-16:42
Ugglaok so thanks for joining this meeting, closing now.16:43
Uggla#endmeeting16:43
opendevmeetMeeting ended Tue Oct  7 16:43:34 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:43
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-07-16.00.html16:43
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-07-16.00.txt16:43
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2025/nova.2025-10-07-16.00.log.html16:43
elodillesthanks o/16:43
fwieselThanks!16:44
Ugglaelodilles, you are welcome16:44
bauzasUggla: thanks 16:46
bauzasdansmith: found why we didn't found the fill_metadata issue with the unittests16:54
dansmithmelwitt: question/sanity-check for you16:54
dansmithmelwitt: in https://review.opendev.org/c/openstack/nova/+/94250216:54
bauzasbut I wonder how to fix the coverage16:54
bauzasanyway, just looking at the time, I need to leave now :(16:55
dansmithbauzas: I still haven't heard a problem in the code I agree with, but .. go on :)16:55
dansmithack16:55
bauzasvery quickly16:55
bauzas                inst.system_metadata = utils.instance_sys_meta(16:55
bauzas                    updated[inst.uuid])16:55
melwittdansmith: looking16:55
bauzasthat's what I fixed16:55
bauzasbecause we were having a dict of dict16:56
dansmithbauzas: oh the dict thing, right, but I also want to know why it passed our QE...16:56
dansmithbauzas: anyway, put up a full patch and I'll look16:56
bauzasbut given the instances you createed in https://github.com/openstack/nova/commit/420050cf33dd58bc6b608540fc8f32b2f65ef274 don't have any metadata recorded in DB, then it always returns an empty dict16:57
bauzasdansmith: ack, will upload a patch and try to write some comment + some pastebin 16:57
bauzasI need to leave for tai-chi but hopefully be back around 7pm UTC16:57
bauzaslong story short, I need to find a way to persist some metadata for the instances you create in test_fill_metadata() so that when calling db.instances_fill_metadata() we get those values for adding them into the object metadata itself16:59
bauzasmy brain is fried and I have to run errand16:59
dansmithokay17:00
dansmithmelwitt: I think you're going to say it's expected behavior and it looks like the resize patch has a lot of conversion logic..17:01
dansmithI'm not sure if I think it's problematic behavior, but it's very much not what I expected17:02
melwittdansmith: yes I am typing that. I think the main issue is that in the 'user' patch the resize is not looking at image_hw_ in sysmeta but it should be (ignoring all of these patches ...) so I'm currently confused about that17:02
dansmithbecause I don't know how to reconcile when the flavor and image disagree (especially in this case where I haven't set anything on my image)17:03
dansmithmelwitt: if it's not looking at image_hw_tpm_security then I don't know why it let me schedule to a user host when the flavor requests a host host17:04
melwittdansmith: yeah. that's what I was chatting with sean about last week is, is this going to be a problem that we have overloaded the image_hw_tpm_secret_security sysmeta key when it did not necessarily come from any image17:04
melwittdansmith: it's because there is no trait filtering logic yet at that point in the series. it knows nothing about 'host' at this point so it's treating it as if it doesn't exist. it is still 'user' despite the fact that it lets you set the flavor as 'host'17:05
dansmithmelwitt: eh? isn't this the trait filtering? https://review.opendev.org/c/openstack/nova/+/942502/19/nova/scheduler/request_filter.py17:06
melwittdansmith: so I guess maybe what I need to do is at least make it know about the "will-be-valid" values early on to reject them until support is introduced17:06
dansmithoh,17:06
dansmithyou mean because it lets any security it doesn't know about through17:06
melwittyes17:06
dansmithack, so that should probably have an else: False or something17:07
dansmith(if false means fail, I don't remember)17:07
melwittit's confusing because resize is allowed today for TPM, so 'user' is just current behavior so it's always going to work until support for the others like 'host' and 'deployment' are added17:07
dansmithwell,17:08
melwittI agree there is a problem here, just thinking of what the best way to deal with it17:08
dansmithI would think it should be security=flavor.get('security', 'user') and not "security is something I don't recognize, so MEH WFM17:08
dansmithbecause the extra spec lets you set =host right now, which is fine, but we should not just ignore that I think17:09
melwittit is, but if you specify 'host', it will set that. it just doesn't know what that is yet17:09
dansmithwell, right.. I just mean dropping out the bottom for unsupported-as-of-yet values17:10
melwittyeah I agree, that's what I was trying to say a minute ago is that I think I need to add awareness of what the valid values are so far and reject anything that is not17:10
dansmithand even when they're all there, I think not allowing a security that it doesn't know about (regardless of how that got in there) is a better plan17:10
melwittyeah, agree17:10
dansmithyeah17:10
melwittI'll update the patch to do that17:11
dansmithcool, just commented on the missing else17:12
melwittthanks17:12
opendevreviewsean mooney proposed openstack/nova-specs master: Add ResourceProviderWeigher scheduler spec  https://review.opendev.org/c/openstack/nova-specs/+/95122219:02
opendevreviewsean mooney proposed openstack/nova-specs master: Add ResourceProviderWeigher scheduler spec  https://review.opendev.org/c/openstack/nova-specs/+/95122219:19
opendevreviewMerged openstack/nova master: [nova-tox-py312-threading]Ignore failing tests  https://review.opendev.org/c/openstack/nova/+/96178120:36
opendevreviewJohn Garbutt proposed openstack/nova master: Fix ironic rebuild with API >=2.93  https://review.opendev.org/c/openstack/nova/+/96329821:36

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!