Earlier  
Posted Nick Remark
#openstack-nova - 2025-12-11
17:33:22 JayF I mean, yeah. Ironic has been dealing with problems shaped like that for years, with Nova computes being the thing we outscale
17:33:29 JayF and we figured it out (shards and conductor groups)
17:35:35 noonedeadpunk and cell_mappings in nova_api is pretty much used only by superconductor, right? So when cell mapping is not templated, but you need to update password, you pretty much caring about config change and restart of superconductor with cell mapping change?
17:39:10 noonedeadpunk and it feels like with rabbitmq quorum queues and using streams for fanouts, rabbit become more horizontally scalable then it used to be... but yeah...
17:43:12 sean-k-mooney melwitt: they are not entirly but i think they are related
17:44:12 sean-k-mooney melwitt: https://bugs.launchpad.net/nova/+bug/2132020 depend o nthe way the error happened.
17:44:29 sean-k-mooney basiclly if we have berried the isntance in cell 0 because of a no valid host
17:44:58 sean-k-mooney then we shoudl free any placment allcation on comptue nodes for it
17:45:08 sean-k-mooney the same way we do when you shelve offload
17:45:24 sean-k-mooney if the isntance is in error but insthace.host is pointing at a real host
17:45:28 sean-k-mooney then we need to keep the allcation
17:45:28 melwitt I'm saying it's not 100% clear whether that's consistent bc currently any instance that has an instance record consumes quota
17:45:38 sean-k-mooney because in thiory you coudl rebuild ro hard reboot the vm
17:46:03 sean-k-mooney we do the instnace count check sepreaty form the palcmenet allcation
17:46:26 sean-k-mooney i think the orgianll assution is the qutota violation is not for the instnace quota
17:48:40 melwitt yeah, I dunno. it is just not 100% clear to me what to do to make sure things are consistent
17:49:39 sean-k-mooney i dont know if you have had time to look at the regression test https://review.opendev.org/c/openstack/nova/+/969251
17:49:52 sean-k-mooney im still trying to figure out if it is valid base don that for waht its worht
17:50:13 sean-k-mooney the two just seam realted to me and i wanted to make sure we were not tryint to solve the same thing in two diffent ways
17:50:45 melwitt no I only skimmed
17:51:09 sean-k-mooney the repoducer has not conviced me its an actula bug yet for what its worth
17:53:06 sean-k-mooney it looks like they actully might be using the logic form https://opendev.org/openstack/nova/src/branch/master/nova/tests/functional/regressions/test_bug_1806064.py#L92
17:53:19 sean-k-mooney to simulate this so maybe it is the num isntance quota
17:53:45 sean-k-mooney to me if we exceed quota but are not shcduled to a host as a restl of it we shoudl not eb preventign other instances form using that space
17:54:04 sean-k-mooney but we obviously cant delete the allcaiton if there si any change of htis vm being recovered
17:54:25 sean-k-mooney i.e. with reset state or rebuidl or whatever
17:54:49 melwitt yeah
17:56:27 melwitt I see the point about not preventing other instances from building. I was thinking about it focused on just the instance but thinking about it focused on the compute hosts I see the issue
17:58:38 melwitt superficially thinking about it I think each fix does have to be in a different place (conductor vs compute/api) because the allocation creation and volume reservation happen at different places
17:59:53 melwitt if you exceed quota in compute/api and a reserved volume was created, you have to clean it up there and you won't have any allocations yet
18:00:42 melwitt I'm actually not sure how quota is getting exceeded in conductor, if it is, then that would be the "quota recheck" step after the compute/api quota check passed
18:01:32 melwitt which is valid of course. just also highlighting how each bug is about a different point in the server create path
18:06:29 opendevreview Jay Faulkner proposed openstack/nova master: [ironic] Use constants from Ironic, test w/ddt https://review.opendev.org/c/openstack/nova/+/969321
18:19:12 JayF https://review.opendev.org/c/openstack/nova/+/969321 is a follow-up to the Ironic bugfix, I did some changes in Ironic's side so we could just copy over the file that becomes ironic_states.py in our driver, to help make it easier to keep states synced. Also updated the tests (as requested on the previous patch) to use ddt.
18:19:33 JayF No real urgency behind landing it, but I would like to get it in since I did the refactor on Ironic's side to make that constants file able to be copied around
18:55:25 sean-k-mooney melwitt: it can only execced in the conductor if 2 api request happen to diffent api isntance at almost the same time
18:55:35 sean-k-mooney so it rare but its possibel
18:56:05 sean-k-mooney well that or if an amdin change the quota while the request is in flight
18:56:21 sean-k-mooney i.e. after its pass the api
18:59:02 melwitt right
20:51:46 opendevreview Merged openstack/nova master: Drop direct dependency on iso8601 https://review.opendev.org/c/openstack/nova/+/943083
#openstack-nova - 2025-12-12
09:13:19 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: create generic check for mem encryption support by host https://review.opendev.org/c/openstack/nova/+/967969
09:13:20 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: remove explicit SEV dependency from nova.scheduler.utils https://review.opendev.org/c/openstack/nova/+/967971
09:13:20 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: stop using _get_mem_encryption_config() for SEV checks https://review.opendev.org/c/openstack/nova/+/967970
09:13:21 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973
09:13:21 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972
09:13:22 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974
10:32:16 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron subnets https://review.opendev.org/c/openstack/nova/+/962190
10:32:16 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron networks https://review.opendev.org/c/openstack/nova/+/928022
10:32:17 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron floating IPs https://review.opendev.org/c/openstack/nova/+/962604
10:32:17 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron extensions https://review.opendev.org/c/openstack/nova/+/962270
11:29:30 stephenfin sean-k-mooney: gmaan: Do you think you'd be able to get to the outstanding openapi patches this side of new year? I'd *really* like to be able to close that one off in 2025
11:29:48 stephenfin as always, I am happy to trade reviews
15:04:57 nicolairuckel tkajinam: I took a look at your patch and you put a todo there for clearing the NVRAM in certain situations. Do you plan on implementing that in that patch too?
15:05:37 nicolairuckel I'm asking because if you'd implement that already, I can just focus on copying the NVRAM and if my patch gets merged after yours, there shouldn't be any problems.
16:20:46 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron subnets https://review.opendev.org/c/openstack/nova/+/962190
16:20:46 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron networks https://review.opendev.org/c/openstack/nova/+/928022
16:20:47 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron floating IPs https://review.opendev.org/c/openstack/nova/+/962604
16:20:47 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron extensions https://review.opendev.org/c/openstack/nova/+/962270
16:23:20 opendevreview Lajos Katona proposed openstack/nova master: WIP: Use SDK for Neutron Ports https://review.opendev.org/c/openstack/nova/+/969298
#openstack-nova - 2025-12-13
12:07:13 opendevreview Dmitriy Chubinidze proposed openstack/nova master: doc: Enabling of using LibvirtDriver for compute node https://review.opendev.org/c/openstack/nova/+/939325
#openstack-nova - 2025-12-14
17:49:47 opendevreview Doug Goldstein proposed openstack/nova-specs master: Expose vlan trunking in metadata/configdrive https://review.opendev.org/c/openstack/nova-specs/+/471815
#openstack-nova - 2025-12-15
01:10:24 opendevreview yangjianfeng proposed openstack/nova master: nova-manage: suport force heal allocations without instance uuid https://review.opendev.org/c/openstack/nova/+/970994
09:18:50 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: make RP creation independent of specific encryption models https://review.opendev.org/c/openstack/nova/+/967972
09:18:50 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: remove explicit SEV dependency from nova.scheduler.utils https://review.opendev.org/c/openstack/nova/+/967971
09:18:51 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: adjust requirement checks for mem_encryption guests https://review.opendev.org/c/openstack/nova/+/967974
09:18:51 opendevreview Taketani Ryo proposed openstack/nova master: mem-enc: refactor _guest_configure_mem_encryption() for extensibility https://review.opendev.org/c/openstack/nova/+/967973
13:11:12 opendevreview Stephen Finucane proposed openstack/nova master: tests: Fix bound https://review.opendev.org/c/openstack/nova/+/971038
13:42:48 opendevreview Doug Goldstein proposed openstack/nova-specs master: Expose vlan trunking in metadata/configdrive https://review.opendev.org/c/openstack/nova-specs/+/471815
15:27:58 opendevreview Lajos Katona proposed openstack/nova master: Use SDK for Neutron Ports https://review.opendev.org/c/openstack/nova/+/969298
15:28:12 Uggla Nova meeting in around 30mn
15:31:39 opendevreview Johannes Kulik proposed openstack/nova master: WIP: Attaching a volume returns HTTP 202 https://review.opendev.org/c/openstack/nova/+/971068
16:02:30 tkajinam Uggla, are you starting the meeting ? :-)
16:02:38 Uggla yep
16:03:43 opendevmeet The meeting name has been set to 'nova'
16:03:43 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:43 opendevmeet Meeting started Mon Dec 15 16:03:43 2025 UTC and is due to finish in 60 minutes. The chair is Uggla. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:43 Uggla #startmeeting nova
16:03:50 Uggla Hello everyone
16:03:57 elodilles o/
16:05:38 tkajinam o/
16:06:10 Uggla Let's slowly start
16:06:15 Uggla #topic Bugs (stuck/critical)
16:06:23 Uggla #info No Critical bug
16:06:25 bauzas o/
16:06:34 Uggla #topic Gate status
16:06:42 Uggla #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:06:50 Uggla #link https://etherpad.opendev.org/p/nova-ci-failures-minimal
16:06:56 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 status
16:07:02 Uggla #info Please look at the gate failures and file a bug report with the gate-failure tag.
16:07:08 Uggla #info Please try to provide a meaningful comment when you recheck
16:07:53 Uggla I had done just a quick glance at the gates, I have not seen something wrong. Please tell me if I'm wrong.
16:08:45 gmaan o/
16:09:19 Uggla hi gmaan, cool you are joining.
16:09:24 Uggla #topic tempest-with-latest-microversion job status
16:09:30 Uggla #link https://zuul.opendev.org/t/openstack/builds?job_name=tempest-with-latest-microversion&skip=0
16:09:39 Uggla gmaan anything to say about this topic ?
16:09:44 gmaan no progress on this.
16:10:50 Uggla btw, because some priorities are changing, if you wish we can remove this topic from the agenda.
16:10:54 fwiesel o/

Earlier   Later