Wednesday, 2025-11-26

*** mhen_ is now known as mhen02:27
*** ykarel_ is now known as ykarel05:59
opendevreviewJulien LE JEUNE proposed openstack/nova stable/2024.2: Update start_service() function in test  https://review.opendev.org/c/openstack/nova/+/96384809:39
opendevreviewJulien LE JEUNE proposed openstack/nova stable/2024.2: Adds regression test for bug LP#2085135  https://review.opendev.org/c/openstack/nova/+/96384909:39
opendevreviewJulien LE JEUNE proposed openstack/nova stable/2024.2: Reset the mapped field of nodes at service deletion  https://review.opendev.org/c/openstack/nova/+/96385009:39
Ugglagmaan, lgtm. +1 on https://review.opendev.org/c/openstack/nova/+/968410, I have added bauzas and gibi because I think we can go ahead.09:58
opendevreviewDominik proposed openstack/nova master: Remove Placement allocations in the broken build cleanup  https://review.opendev.org/c/openstack/nova/+/96844611:27
gibidansmith: bauzas: Uggla: Kamil: I need to skip the eventlet sync today. Sorry. Feel free to have it without me.13:55
gibisean-k-mooney: ^^13:55
sean-k-mooneyack, i have a meeting before it which might over run so i may or may not be there either13:59
sean-k-mooneygibi: heh fun, you know the way we say we dont reallly supprot runing addtional libvirt vms on the same host even though its techinally possible14:04
sean-k-mooneyhttps://paste.opendev.org/show/beuKA1lA9Pt5xDTYYwJR/14:04
sean-k-mooneythis is one of hte way tha tcan break things14:04
sean-k-mooneybasicaly if nova cant access the disk images then it would break update aviable resouces14:05
noonedeadpunksean-k-mooney: hey! have a discussion point around one of the comment on https://review.opendev.org/c/openstack/nova-specs/+/900296/7/specs/2026.1/approved/cross-az-instance-scheduling.rst if you have a minute14:41
noonedeadpunkI've addressed all points (did not push them yet), except `cross_az_attach`14:41
noonedeadpunkAs my way of thinking was that I don't need care about that in this spec, as it will be handled here anyway: https://opendev.org/openstack/nova/src/commit/23b462d77df1a1d09c43d0918bca853ef3af1e3f/nova/compute/api.py#L1429-L143014:41
noonedeadpunkso if it won't be matching, `MismatchVolumeAZException` will be raised14:42
opendevreviewJulien LE JEUNE proposed openstack/nova stable/2024.2: Update start_service() function in test  https://review.opendev.org/c/openstack/nova/+/96384814:49
opendevreviewJulien LE JEUNE proposed openstack/nova stable/2024.2: Adds regression test for bug LP#2085135  https://review.opendev.org/c/openstack/nova/+/96384914:49
opendevreviewJulien LE JEUNE proposed openstack/nova stable/2024.2: Reset the mapped field of nodes at service deletion  https://review.opendev.org/c/openstack/nova/+/96385014:49
sean-k-mooneynoonedeadpunk: so cross_az attach is a per compute node opiton14:49
noonedeadpunkit seems it's currently verified on api side already?14:50
noonedeadpunkas iirc nova.compute.api is api-side?14:50
sean-k-mooneymy point is if you dont configure in the api and only configure it the comptue nodes which is allowed then it will fail late14:51
noonedeadpunkoh, yes14:51
noonedeadpunkbut I think it's already the case today? I am just thinking if this is smth which should be addressed in spec at all14:51
sean-k-mooneywe just need to document that in the spec14:52
sean-k-mooneyin generally i woudl prefer to remove that config option entirly and either replace it with nothing or a flavor extra spec14:52
sean-k-mooneythis shoudl never have been setable on a per compute basis14:52
sean-k-mooneybut that proably not somethign we can do at this point14:53
noonedeadpunkthe reason why I'm raising this, is that we are actually having cross_az_attach=False here....14:53
noonedeadpunkAnd made it working *somehow*14:53
sean-k-mooneyit built on the false premiss that nova AZ names and AZ names in any other service shoudl align14:53
noonedeadpunkIn *some* cases...14:53
sean-k-mooneyso if you set cross_az_attach=False in the api then we will end up pinnign the vm to the az of the voluem if and only if you pass in a volume14:54
noonedeadpunkSo I'd really love to leave "status quo" for this specific spec wrt cross_az_attach14:54
sean-k-mooneyif on the other hand nova creates the voluem i dont think we pin it because we create teh volume after schdulign i think14:55
noonedeadpunkYes, I think it's true actually14:55
sean-k-mooneynoonedeadpunk: yes im not asking you to change the behvior fomr today14:55
sean-k-mooneyjust document what it iss14:55
noonedeadpunk++14:55
noonedeadpunkok, shoot...14:55
noonedeadpunkso basically, it would make things worse, or indeed I'd need to address that in implementation....14:56
noonedeadpunkor well...14:56
sean-k-mooneyyou can litrally punt an just say "this will not change the behvior of cross_az_attach" and if its disabel then it will fail if there is a confilct14:56
noonedeadpunk++14:57
noonedeadpunkI am literally failing now to set in my head cross_az_attach behavior in all scenarios....14:57
noonedeadpunkok, thanks, will do that then14:58
sean-k-mooneyyep because its stupily complicated. the default is true which mean sthe api does nto condier the voluem az by default14:59
sean-k-mooneyif you only set it to false on the compute we only check it there14:59
sean-k-mooneyif you onely set it on the api we will validate teh az request in the build request vs the volume15:00
sean-k-mooneyand we will use the volume's az if there isnt a conflict 15:00
sean-k-mooneythere is some other behvior thace chages as well15:00
noonedeadpunkunless you create an instance with `--boot-fropm-volume`15:00
sean-k-mooneyyep in which case the voluem i think get create on the compute node :)15:01
opendevreviewDmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint  https://review.opendev.org/c/openstack/nova-specs/+/90029615:02
opendevreviewDmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint  https://review.opendev.org/c/openstack/nova-specs/+/90029615:12
opendevreviewMerged openstack/nova-specs master: Re-propose vTPM live migration  https://review.opendev.org/c/openstack/nova-specs/+/96156417:21
tkajinamdansmith, hi ! It'd be nice if you can spare some time to check this discussion with Uggla https://review.opendev.org/c/openstack/nova-specs/+/966584/comment/24e4946c_0522d2cf/ ,regarding how we handle firmware used by existing vms during hard-reboot.17:26
* tkajinam might be offline soon, though17:27
dansmithokay I'll try.. my list is stacked pretty deep and we're off the rest of the week here, as you probably know17:27
tkajinamdansmith, thx and yeah I heard that17:29
tkajinamI'll check with Uggla if I can update that part later (after merging the current version) or I can get spec freeze exception, if we need some more time/discussions17:30
Ugglatkajinam, that's ok for me17:31
opendevreviewWill Szumski proposed openstack/nova master: Randomise best hosts  https://review.opendev.org/c/openstack/nova/+/96854418:47
opendevreviewSean Mooney proposed openstack/nova master: [WIP] create ResourceSummaryNotification object  https://review.opendev.org/c/openstack/nova/+/96855819:56

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