Earlier  
Posted Nick Remark
#openstack-nova - 2023-11-22
09:25:28 bauzas oh shit, you're tight
09:25:31 bauzas right*
09:26:37 bauzas ETOOMANYTHINGSINMIND
09:26:41 bauzas +2d
09:26:48 bauzas (the bobcat one)
09:28:31 gibi thanks!
09:29:59 opendevreview Balazs Gibizer proposed openstack/nova stable/2023.2: Allow enabling cpu_power_management with 0 dedicated CPUs https://review.opendev.org/c/openstack/nova/+/901656
09:30:13 gibi bauzas: now it is the time to look away ^^ ;)
09:30:25 bauzas lol
09:31:12 opendevreview Balazs Gibizer proposed openstack/nova stable/2023.1: Allow enabling cpu_power_management with 0 dedicated CPUs https://review.opendev.org/c/openstack/nova/+/901660
09:35:37 dvo-plv Hello, All Maybe you will have a chance to review spec file and patch today
09:35:38 dvo-plv https://review.opendev.org/c/openstack/nova-specs/+/895924
09:35:43 dvo-plv https://review.opendev.org/c/openstack/nova/+/876075
10:47:53 auniyal6 Hi bauzas, sean-k-mooney can you please approve this one again https://review.opendev.org/c/openstack/nova/+/901604
13:48:15 opendevreview Merged openstack/nova stable/yoga: [stable-only] Remove nova-emulation from check pipeline of Yoga https://review.opendev.org/c/openstack/nova/+/901604
14:45:39 opendevreview Andriy Kurilin proposed openstack/python-novaclient master: [DNM] Try to debug functional https://review.opendev.org/c/openstack/python-novaclient/+/901677
14:53:06 opendevreview Sylvain Bauza proposed openstack/nova master: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/899625
14:53:29 bauzas sean-k-mooney: fwiw, my capping vpgu bugfix is now done ^
14:53:47 bauzas you can test it if you want, it also works with non-SRIOV GPUs
17:47:46 opendevreview Merged openstack/nova stable/yoga: libvirt: remove default cputune shares value https://review.opendev.org/c/openstack/nova/+/898554
#openstack-nova - 2023-11-23
01:05:34 melwitt gmann: there is a patch to unblock the python-novaclient gate https://review.opendev.org/c/openstack/python-novaclient/+/901621 that I have +2ed that you might want to look at. it's a very weird thing with failing when NEUTRON_ENFORCE_SCOPE = true
02:54:32 gmann melwitt: checking
03:01:05 gmann melwitt: done, yeah strange error. seeing from old and new rule existing token should pass either it is admin or member role token
04:36:10 opendevreview Merged openstack/python-novaclient master: Disable NEUTRON_ENFORCE_SCOPE at function job https://review.opendev.org/c/openstack/python-novaclient/+/901621
07:58:55 opendevreview Takashi Kajinami proposed openstack/nova master: Detect maximum number of SEV guests automatically https://review.opendev.org/c/openstack/nova/+/899381
08:00:27 tkajinam sean-k-mooney, bauzas ^^^ I've created as bp https://blueprints.launchpad.net/nova/+spec/libvirt-detect-sev-max-guests and link it from the change, as suggested
08:00:40 tkajinam I've not created any bp for a while so lmk if I made something wrong ...
08:41:40 gibi tkajinam: good to see you around :) The BP looks good to me
08:42:58 gibi bauzas: ^^ do we need to wait for the next nova meeting to approve that or we already agreed about the feature and this is just paperwork?
08:44:34 tkajinam gibi, hey. good morning and hope everything is good with you. thanks for checking the bp :-D
08:49:35 bauzas lgtm, I can stamp the paperwork
08:51:20 bauzas tkajinam: gibi: sean-k-mooney: bp approved as specless, good to go for reviews
08:56:48 gibi bauzas: cool
08:57:09 gibi tkajinam: yeah all good here. Hope all good on your side too
08:57:38 bauzas tkajinam: btw. saw your email on tooz
08:58:04 bauzas fwiw, I agree with the concerns, we rather need tooz to continue to verify the older API
08:58:56 bauzas even if we say to our operators that they should first upgrade their environment to the last minor .y version before SLURP upgrading, some of them could not do that for tooz
08:59:05 bauzas given it's a library
08:59:46 SvenKieske anybody has seen this qemu issue anywhere? https://gitlab.com/qemu-project/qemu/-/issues/1069
09:08:31 tkajinam gibi, all good on my side as well :-)
09:09:16 tkajinam bauzas, thanks for the approval !
09:13:57 tkajinam bauzas, hmm the limitation caused by hard-coded api version can't be fixed in older tooz unfortunately (because of the fact tooz is branchless) though the proposed change should ease the pain caused by etcd versions.
09:14:35 tkajinam bauzas, and I agree that we need tooz to continue to verify the older API. The proposed API detection mechanism should work for older tooz but we probably have to have a few functional tests to verify it with older etcd
09:15:07 bauzas to be clear, grenade and devstack are just coal canaries
09:15:35 bauzas the problem is the SLURP upgrade, which implies that you don't need to lockstep both the openstack upgrade and the OS upgrade
09:15:46 bauzas well, that's not a problem, that's rather a tenet
09:16:08 bauzas operators aren't forced to upgrade their OSes during openstack upgrade itself
09:16:37 bauzas that's why we have PTIs that continue to support old OS releases during 2 SLURP cadences
09:16:37 tkajinam I agree
09:17:39 tkajinam yes
09:18:30 bauzas the problem is that tooz is branchless
09:18:59 bauzas but new tooz (which would be upgraded during the SLURP release) still needs to talk like the old tooz was doing, against an old etcd API
09:19:08 bauzas we don't need to backport anything
09:19:34 bauzas or ask the operators to minor-uprgade their libs before the SLURP upgrade
09:21:27 gibi bauzas: the SEV slot autodetection impl patch is fairly simple and I'm +2 on it, so I think it is an easy win :)
09:21:44 tkajinam I'm not too sure how many users may maintain tooz independently from OpenStack. usually it's bundled to OpenStack in distros for example. (The tooz package comes from UCA or RDO afair)
09:21:45 tkajinam but
09:22:38 tkajinam bauzas, I think your concern should be cleared by the change I proposed to tooz. the old tooz was able to talk with old etcd without api version override. now with the change new tooz is able to talk with old etcd without api version override so the default behavior is same before/after updating tooz
09:23:29 bauzas ++
09:24:46 tkajinam gibi, thanks :-D
09:33:12 opendevreview Haidong Pang proposed openstack/nova master: Corrected allocation deletion error during live migration. https://review.opendev.org/c/openstack/nova/+/901721
10:36:30 sean-k-mooney tkajinam: i approved the patch gibi thanks for reviewing
10:38:22 sean-k-mooney tkajinam: specifically https://review.opendev.org/c/openstack/nova/+/899381 thanks for paying donw that technial debt
11:52:30 dvo-plv sean-k-mooney, gibi Do you have a time today to review this proposal ? https://review.opendev.org/c/openstack/nova-specs/+/895924
11:52:35 dvo-plv https://review.opendev.org/c/openstack/nova/+/876075
12:18:36 sean-k-mooney i readded my +2 to the spec
12:18:44 dvo-plv thanks
12:18:51 sean-k-mooney im not sure ill have time to review the code today but ill see how my day goes
12:19:19 sean-k-mooney if i dont get to it today feel free to ping me on monday (im on pto tomorrow)
12:19:47 sean-k-mooney i was largely happy with the implemation before so if you have adress gibis previous comments in the nova patch
12:20:10 sean-k-mooney then its likely that nova patch is more or less ready to merge unless we see anything else on this revions
12:22:22 dvo-plv sure, thanks
17:01:37 auniyal6 Hi dansmith, just a reminderto review https://review.opendev.org/c/openstack/nova/+/865336
17:03:22 auniyal6 you said earlier "will chat with sean-k-mooney about it when he's back before I review/approve"
17:04:05 auniyal6 this only walaby is pending https://review.opendev.org/q/topic:%22bug/1970467%22
18:13:27 opendevreview Merged openstack/nova master: Detect maximum number of SEV guests automatically https://review.opendev.org/c/openstack/nova/+/899381
18:21:35 sean-k-mooney artom: Uggla_ if you get around to revisiting https://review.opendev.org/c/openstack/nova/+/877773 i left a -1 and some chagnes that would be required fro that to be backporable.
18:31:21 artom sean-k-mooney, you're insane :)
18:31:29 artom I mean that in the best way possible
18:32:45 artom At least you wrapped it in a @property
#openstack-nova - 2023-11-24
04:17:26 opendevreview Rajesh Tailor proposed openstack/nova master: Add upgrade status check for duplicate cell names https://review.opendev.org/c/openstack/nova/+/901810
04:50:31 opendevreview Rajesh Tailor proposed openstack/nova master: Handle InstanceExists exception for duplicate instance https://review.opendev.org/c/openstack/nova/+/860938
08:00:41 opendevreview Rajesh Tailor proposed openstack/nova master: Add retry on attachment_update https://review.opendev.org/c/openstack/nova/+/901815
08:04:44 opendevreview Rajesh Tailor proposed openstack/nova master: Add retry on attachment_update https://review.opendev.org/c/openstack/nova/+/901815
08:10:49 opendevreview Haidong Pang proposed openstack/nova master: Catch MessagingTimeout during evacuation https://review.opendev.org/c/openstack/nova/+/901817
10:01:14 opendevreview Amit Uniyal proposed openstack/nova master: enforce remote sonsole shutdown https://review.opendev.org/c/openstack/nova/+/901824
10:22:46 bauzas gibi: thanks for having commented https://review.opendev.org/c/openstack/nova/+/899625
10:22:58 bauzas good point, I haven't verified about providing *,*
13:44:53 bauzas gibi: sean-k-mooney: got a sec for discussing about https://review.opendev.org/c/openstack/nova/+/899625/ ?
13:46:44 bauzas if not, no worries
13:46:51 bauzas lemme explain what I'll do
13:48:28 bauzas first, I'll work on pas-ha[m] patch https://review.opendev.org/c/openstack/nova/+/899406 for having it as a dependency for https://review.opendev.org/c/openstack/nova/+/899625/
13:49:10 bauzas secondly, I'll split my own patch in two, one for let's make device_addresses to be None
13:49:24 bauzas (instead of a wildcard)
13:49:42 bauzas and then, the third change will be https://review.opendev.org/c/openstack/nova/+/899625/ without the wildcard
13:49:48 bauzas pas-ha[m]: are you around?
14:12:14 bauzas pas-ha[m]: fwiw, I'm gonna add a few UTs
14:12:18 bauzas to your patch
14:18:49 pas-ha[m] bauzas: hi, sure
14:20:12 bauzas on it already, shall be quick hopefully

Earlier   Later