Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-11-29
14:20:03 opendevreview Elod Illes proposed openstack/nova stable/zed: add a regression test for all compute RPCAPI 6.x pinnings for rebuild https://review.opendev.org/c/openstack/nova/+/900307
14:20:04 opendevreview Elod Illes proposed openstack/nova stable/zed: Fix rebuild compute RPC API exception for rolling-upgrades https://review.opendev.org/c/openstack/nova/+/900341
14:20:05 opendevreview Elod Illes proposed openstack/nova stable/zed: Adding server actions tests to grenade-multinode https://review.opendev.org/c/openstack/nova/+/900342
14:29:01 elodilles bauzas: i've updated the zed version of the 'RPC backports', please review if you want them included in the zed release ^^^
14:29:26 bauzas sure
14:29:45 bauzas gibi: do you want https://review.opendev.org/c/openstack/nova/+/901656 to be in the first Bobcat z release ?
14:35:21 gibi bauzas: ohh we can try a recheck but I don't want to hold the release
14:37:03 bauzas just rechecked
14:37:07 gibi me too :D
14:37:15 gibi thanks for the ping
14:37:29 bauzas gibi: looks not me wasn't due to a ssh issue
14:38:03 bauzas oh, you looked at the other job failure
14:38:08 bauzas my bad
14:48:18 gibi no worries :)
14:56:12 dvo-plv gibi, Maybe you will have a hance to review this one ?
14:56:13 dvo-plv https://review.opendev.org/c/openstack/nova-specs/+/895924
14:56:19 dvo-plv and this
14:56:19 dvo-plv https://review.opendev.org/c/openstack/nova/+/876075
16:54:07 bauzas gibi: sean-k-mooney: before I leave, so about https://review.opendev.org/c/openstack/nova/+/902084/1
16:54:16 bauzas we have two possibilities :
16:54:24 bauzas 1/ use a star like I did
16:54:42 bauzas 2/ let device_addresses be optional
16:55:08 bauzas this way,
16:55:23 bauzas https://paste.opendev.org/show/bbw8uYTcDqasoSSD54WD/ would be acceptable
16:55:24 sean-k-mooney if we have fxed https://review.opendev.org/c/openstack/nova/+/899406/2
16:55:31 sean-k-mooney then i think it can be optional
16:56:04 bauzas that's a bit differenbt
16:56:21 sean-k-mooney that is fixing the fact that if you have just enabled_mdev_types = nvidia-35
16:56:27 sean-k-mooney device_addresses
16:56:32 bauzas pas-ha[m] change is accepting to only use one type but with a section
16:56:37 bauzas yeah
16:56:41 sean-k-mooney ya so
16:57:00 sean-k-mooney without that i dont think device_adderss being optional is really a good approch
16:57:04 bauzas so, my WIP (if we make dev_add optional) would change the existing behaviour
16:57:06 sean-k-mooney btu if we fix that then im fine with it
16:57:39 bauzas which is that if you use two types but only one got a section, then none of them use any section
16:58:08 bauzas not sure we could backport that
16:58:13 sean-k-mooney thats a bug right
16:58:22 bauzas not really
16:58:29 sean-k-mooney it kind of is
16:58:45 sean-k-mooney im aware of the legacy behavior for the first type
16:58:53 bauzas https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7938-L7951
16:59:00 sean-k-mooney but the second adn subsquent type are ment ot have a section
16:59:23 bauzas this conditional makes all types needing to have groups for each of them
16:59:23 sean-k-mooney and we shoudl not ignore them if they are defiend just because the first type does not ahve one
16:59:48 bauzas sure, I'm just changing this is a bit of a behavioural change
16:59:59 bauzas which couldn't be acceptable for a backport
17:00:05 sean-k-mooney so i do think all types shoudl have a section in general
17:00:15 sean-k-mooney however that only makes snese if there is somethign in it
17:00:18 bauzas you do or don't ?
17:00:55 sean-k-mooney i think we shoudl requrie a section for each mdev type unconditonally
17:00:59 sean-k-mooney personlaly
17:01:11 sean-k-mooney but wiether device_adresss is required or not is a sperate question
17:01:51 bauzas so you'd prefer to have https://paste.opendev.org/show/bKc2SjB6l7LILYE0onzG/
17:02:30 sean-k-mooney kind of yes although i would also like to consider if max_instances is requried or not
17:02:33 bauzas if so, that simplifies my change and then we can backport it :)
17:02:57 sean-k-mooney to me https://paste.opendev.org/show/bKc2SjB6l7LILYE0onzG/
17:03:06 sean-k-mooney is you intentionally not setting device_adresses
17:03:08 bauzas I wouldn't require max_instance or only unless device_addresses isn't set
17:03:19 sean-k-mooney and as a result opting into the whild card behavior
17:03:33 bauzas sean-k-mooney: correct, you're saying 'this is a default type for all found GPUs'
17:04:03 bauzas okay, then I'll change my current non-uploaded patch and I'll provide it tomorrow
17:04:11 bauzas thanks sean-k-mooney
17:04:30 sean-k-mooney ack
17:04:41 sean-k-mooney gibi: ^ when you have time does that work for you
17:04:46 bauzas sean-k-mooney: fwiw, https://review.opendev.org/c/openstack/nova-specs/+/900636 is open for reviews :)
17:05:04 sean-k-mooney hehe ya i need to do a review day soon
17:05:08 sean-k-mooney maybe tomorrow
17:05:21 bauzas you're lucky
17:05:28 bauzas my review karma is bad those days
17:06:42 sean-k-mooney https://www.stackalytics.io/report/contribution?module=nova-group&project_type=openstack&days=30 i mean min is not much better for thte last little bit
17:07:27 gibi bauzas: sean-k-mooney: sounds good to me
17:07:34 bauzas thanks gibi
17:07:43 bauzas will upload the patch quickly then
17:29:24 opendevreview melanie witt proposed openstack/nova master: Lower num_pcie_ports to 12 in the nova-next job https://review.opendev.org/c/openstack/nova/+/902175
17:30:05 melwitt sean-k-mooney: from our convo yesterday ^
18:06:20 sean-k-mooney cool lets see if that passses
18:06:34 sean-k-mooney it would only fial if we need more then 12 pci device in a tempest test
18:07:00 melwitt kk
18:07:00 sean-k-mooney we use about 4-6 by defualt and i dont think we are attaching that many volumes or prots to cause an issue
18:26:46 opendevreview Merged openstack/python-novaclient master: add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/python-novaclient/+/899950
19:15:05 opendevreview Merged openstack/nova stable/2023.2: Allow enabling cpu_power_management with 0 dedicated CPUs https://review.opendev.org/c/openstack/nova/+/901656
19:32:17 melwitt argh, it already failed for the non-q35 guest kernel panic https://4a4a1510e17776a8b793-89f5aa2f0368a55b3a90e6b26173438f.ssl.cf2.rackcdn.com/902175/1/check/nova-multi-cell/c2bacb0/testr_results.html
19:33:11 melwitt it meaning the patch, unrelated to the change itself
19:35:17 sean-k-mooney that is a slightly diffent panic
19:35:35 sean-k-mooney it paniced at the same phases switching_root
19:35:43 melwitt right
19:35:53 sean-k-mooney but instead of being in a page fault handeler it was in teh apic timer handeler
19:36:14 sean-k-mooney it still could be OOM related
19:37:15 sean-k-mooney in that case we also dont have any of the io mapping error since it machine_type=pc and using pci not pcie as a result
19:37:28 melwitt that would be my guess
19:37:36 melwitt right
19:38:03 sean-k-mooney so the patch will help with one of the 2 issues but perhaps we shoudl just add 64 mb of swap to the tempest flavors
19:38:44 melwitt I've been comparing a non kernel panic console log with a panic one and one difference I see leading up to it is that the non-panic has this line "info: copying initramfs to /dev/vda1" but the panic one does not
19:39:06 sean-k-mooney https://github.com/openstack/devstack/blob/master/lib/tempest#L293-L306
19:40:30 sean-k-mooney so from here https://github.com/cirros-dev/cirros/blob/46a1162787f669ad8d6065cb6bbe477654b4327f/src/init#L63
19:40:41 melwitt hm ok. so maybe I can try adding swap there and recheck a bunch of times to see if panic happens?
19:40:53 melwitt yes
19:41:22 melwitt so that code block is skipped in the cases where it panics. dunno why
19:41:41 sean-k-mooney so its failing here https://github.com/cirros-dev/cirros/blob/46a1162787f669ad8d6065cb6bbe477654b4327f/src/init#L85

Earlier   Later