Wednesday, 2025-09-10

*** mhen_ is now known as mhen01:57
opendevreviewBalazs Gibizer proposed openstack/nova master: Rally job for eventlet-removal  https://review.opendev.org/c/openstack/nova/+/96013007:53
opendevreviewribaudr proposed openstack/nova master: Add Flamingo prelude section  https://review.opendev.org/c/openstack/nova/+/95918808:40
opendevreviewJulien LE JEUNE proposed openstack/nova master: Adds regression test for bug LP#2044235  https://review.opendev.org/c/openstack/nova/+/96034909:26
Ugglazigo would you be able to rebase your patch 930444: Update Debian qemu/libvirt/libguestfs versions | https://review.opendev.org/c/openstack/nova/+/930444 on top of the one from tkajinam (https://review.opendev.org/c/openstack/nova/+/960301) ?09:33
opendevreviewTakashi Kajinami proposed openstack/nova master: Update Debian qemu/libvirt/libguestfs versions  https://review.opendev.org/c/openstack/nova/+/93044409:46
tkajinamUggla zigo, I've rebased it. I also modified it a bit because Trixie is already GA (UUIC)09:46
Ugglatkajinam 👍09:46
zigotkajinam: Great, thanks a lot !09:48
zigoThis lists versions of qemu, libvirt and so on, right?09:49
zigoGot it: https://docs.openstack.org/nova/latest/reference/libvirt-distro-support-matrix.html :)09:52
opendevreviewMerged openstack/nova master: docs: Update libvirt version support matrix for Flamingo  https://review.opendev.org/c/openstack/nova/+/96030110:03
sean-k-mooneytkajinam: it is but it wont offilaly be supproted until next cycle aka friday11:29
sean-k-mooneytkajinam: once master is reopend im hoping ot finish the work that was started to supprot it in devstack and swap the nova-hybird-plug job form 12 to 1311:30
tkajinamsean-k-mooney, yeah that's true11:32
tkajinamdue to python version11:32
sean-k-mooneyhttps://review.opendev.org/c/openstack/devstack/+/95465311:33
sean-k-mooneytkajinam: no11:33
sean-k-mooneybecuase we select the supproted plathforms before the release starts11:33
sean-k-mooneyand it was not release at the start of 2025.211:33
tkajinamyeah that's true11:33
sean-k-mooneyopenstack seams to work fine on it11:33
sean-k-mooneybut it will be an offical testign runtime form friday11:34
tkajinamthough I thought Trixie uses python 3.1311:34
tkajinamI understand what you mean11:34
opendevreviewMerged openstack/nova master: hypervisors: Optimize uptime retrieval for better performance  https://review.opendev.org/c/openstack/nova/+/95960411:37
opendevreviewMerged openstack/nova master: Update Debian qemu/libvirt/libguestfs versions  https://review.opendev.org/c/openstack/nova/+/93044411:37
opendevreviewJulien LE JEUNE proposed openstack/nova master: Adds regression test for bug LP#2044235  https://review.opendev.org/c/openstack/nova/+/96034911:43
gibiUggla: sean-k-mooney: elodilles: I've sent the question about pyroute2 req rollback to ML and proposed the req patch. https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/FFYMQTJPJREQZ2P32HGS5HE2NLTXHVUC/ and https://review.opendev.org/c/openstack/requirements/+/96036611:56
zigoHi there!12:05
zigoAt my company, we bill instances depending on their resources. ie: if you want a 20GB system disk, you get billed (linearly) for it. Nothing special here.12:05
zigoHowever, there's a problem when customers are doing a boot from volume, and select a flavor that includes a system disk. In this case, they get billed for something they will never be able to use.12:05
zigoSo I wonder, would the team agree for a feature to disallow spawning an instance with boot from volume, if it is with a flavor that has a system disk? Of course, that would be only an option (or a policy ?) and we could keep the usual old (permissive) behavior of the Nova API.12:05
zigoYour thoughts ?12:05
elodillesgibi: ACK, thanks o/ let's see if we get an answer for req folks12:12
elodilless/for/from12:12
sean-k-mooneyzigo: just reading back12:43
sean-k-mooneyzigo: what do you mean by 20GB system disk, do you mean a flavor with nova provisioned storage i.e. root_GB and/or ephmeral_GB >012:44
sean-k-mooneyzigo: i advocated for blockign BFV instnace form using  flavor with root_gb >0 when we prevented non boot form volume instance using flavors with root_gb=012:45
sean-k-mooneyzigo: in the past it was consier too large of a upgrade impact for exisign clouds to make that change12:45
sean-k-mooneyzigo: i dont think we can jsut block it. but what we coudl do is add a policy rule for it12:46
sean-k-mooneywe have a policy rule for allowing non BFV guest to use falvoar with 0 root_gb12:46
sean-k-mooneywe could add one for BFV with flavors that are not 012:47
sean-k-mooneyand then you could configure that to @ or a specific rule other then member12:47
sean-k-mooneyi dont recally if '@' is the sentenil for no one or everyoen but we have sental values for both12:48
sean-k-mooneyzigo: would somethign like that work for you12:48
sean-k-mooneyzigo: one thing that we should not break is bfv with non-zero ephmeral_gb12:49
sean-k-mooneythat is often sued to have the root disk run form say ceph while having an addtion ephmeral disk that uses fast local storage, i.e. for ectd or fast local scratch space12:49
zigo"we could add one for BFV with flavors that are not 0" <--- That's what I would like, yes.12:50
zigoCan it be done with an existing deployment already ?12:51
sean-k-mooneygmaan is on pto but i think that woudl be consitent with our exisitng policies12:51
sean-k-mooneyyes so the policy rule change woudl jsut prevent you creatin new instnace in that state or resizing to that state12:51
sean-k-mooneyso existing workload woudl contiue to work12:52
sean-k-mooneybut if folks use heat/tereform ectra to automate deployment then it woudl break there automation12:52
zigoOk, I'll search how to do it then.12:52
sean-k-mooneyi.e. if they refence specifc flavors12:53
sean-k-mooneyoh12:53
sean-k-mooneyyour asking if it cna be done today12:53
sean-k-mooneyzigo: sorry no12:53
sean-k-mooneyzigo: ill doubel check but i belive we dont have the policy rule today12:53
zigoOk.12:54
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/policies/servers.py#L288-L31212:54
sean-k-mooneythat the existing one we have which does not do what you want but it prevent using an iamge with a 0 disk flavor12:55
sean-k-mooneywe need to add the inverse12:55
sean-k-mooneyzigo: the related config option is https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.max_local_block_devices12:55
sean-k-mooneywhat you could do modify the flavor that have local disk with a forbiden trait12:56
sean-k-mooneythen you could set DEFAULT.max_local_block_devices=0 on a subset of hosts adn use provider.yaml or the api to add a trait to those hosts12:57
sean-k-mooneyyou could also do thie with the aggrate flavor extra specs filter12:57
sean-k-mooneythat woudl turn the combinaiton yuou want to block into a no valid host12:57
sean-k-mooneyhonelsy however that is not a good solution for an existing cloud12:57
sean-k-mooneythat really intended fo diskless blade servers12:58
zigoThanks a lot, that's helpful.12:58
sean-k-mooneyzigo: there is one other non nova thing you coudl consider12:58
sean-k-mooneycurrently i guess your doing flavor based billing12:58
sean-k-mooneyactully it might now work12:59
sean-k-mooneyi was going ot say you could look at the allocation in palcemetn, 12:59
zigoYes we are doing flavor based billing.12:59
zigoAnd today, a customer complained he was billed for a system disk he's not able to use.12:59
sean-k-mooneyi belive ofr BFV guest the allcoation for the instnace will not have disk as part of it for BFV guests13:00
zigoIt's his fault, but for a definitive fix, we should just forbid doing that.13:00
sean-k-mooneywell that debatable nova supprot this but yes you need to acount for that in the billing system as a result13:01
sean-k-mooneyanyway nova zeros out the root disk storage form the flavor for bfv guest in palcement so if you wanted too you shoudl be able ot sue that to bill more acurratly until a new policy rule is intorduced13:02
sean-k-mooneyzigo: would you mind crating a blueprint for this or adding a ptg topic so we have somethign to dicuss and track this request13:03
sean-k-mooneyi dont know if other woudl want a small spec for this but we can dicuss that in the irc meeting once we have a blueprint.13:04
zigosean-k-mooney: Will do, thanks for your input !13:28
dansmithgibi: so on the the s-g parallelize thing.. in fixing the last few tests, I think I've realized that the accounting for the "batches" test(s) was so off because of the sequential processing14:36
dansmithsort of a "yeah, duh" moment14:36
opendevreviewMerged openstack/nova master: Fix bug 2114951  https://review.opendev.org/c/openstack/nova/+/95289514:38
gibidansmith: :)14:48
dansmiththe downside is that the behavior becomes a little less deterministic (as expected) so I'm having to change assertions a bit14:50
sean-k-mooneygibi: so lookign at https://docs.openstack.org/project-team-guide/release-management.html#milestone-3-feature-freeze the requirements freeze starts at m3 and is unfozent on master after the stable branch of the requirement repos created at https://docs.openstack.org/project-team-guide/release-management.html#release-215:29
sean-k-mooneygibi: so taht woudl imply its too late to rolback pyroute2 however i have no idea regarding your other question fo can this happen on stable/2025.2, my gut feeling is no becuase it could break released packages based on rc1 or the ga release, or at the very least cause the pyroute2 package to need a downgrade15:31
sean-k-mooneywith that said im not sure so thanks for sending that email again15:32
gibiyeah I feel we need to roll forward once we have a pyroute2 fix both on master and stable/2025.2 I hope rolling forward will be OK on stable16:14
opendevreviewTakashi Kajinami proposed openstack/nova master: DNM: Drop GLANCE_STANDALONE  https://review.opendev.org/c/openstack/nova/+/96040416:32
sean-k-mooneygibi: my understanding is we are not allowed to raise minversion but we can increase max17:00
sean-k-mooneyso it shoudl be ok as long as theyre is no breaking change17:01
sean-k-mooneyits not something i have seen us do often however so im not very familar with the critia that is applied17:01
opendevreviewsean mooney proposed openstack/nova stable/2025.1: hypervisors: Optimize uptime retrieval for better performance  https://review.opendev.org/c/openstack/nova/+/96040918:30
opendevreviewsean mooney proposed openstack/nova stable/2024.2: hypervisors: Optimize uptime retrieval for better performance  https://review.opendev.org/c/openstack/nova/+/96041018:34
opendevreviewsean mooney proposed openstack/nova stable/2024.1: hypervisors: Optimize uptime retrieval for better performance  https://review.opendev.org/c/openstack/nova/+/96041118:35
opendevreviewCyril Roelandt proposed openstack/nova master: DNM: Drop GLANCE_STANDALONE  https://review.opendev.org/c/openstack/nova/+/96040421:12

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