Earlier  
Posted Nick Remark
#openstack-nova - 2023-11-21
17:44:21 bauzas if some deployment tool automatically enables the power management feature, it still needs to properly document the fact that the strategy can be modifed
17:44:42 bauzas maybe some operators would be surprised to see their cores offlined
17:44:59 bauzas (at least I would)
17:45:24 sean-k-mooney well that kind of raise the question of what the defautl behavior shoudl be upstream
17:45:25 bauzas and maybe it wouldn't hit me that it was nova which offlined them for my usage
17:45:34 sean-k-mooney i think we eventually woudl want to make that the default
17:45:47 sean-k-mooney perhasp even this cycle although that should be a seperate patch
17:46:10 bauzas sean-k-mooney: the problem here is that I don't want us to buy a feature that depends on a kernel support
17:46:42 sean-k-mooney this has been supported in the kernel for a very very long time, although you ar ecorrect that it can be compiled out
17:46:46 bauzas I don't know for exotic archs and kernels, but I don't wanna bet that all of them have the sysfs calls
17:46:55 sean-k-mooney or disabeld such as when in a vm
17:47:20 sean-k-mooney so you dont think we shoudl enabel by default in the long term then?
17:47:52 sean-k-mooney its certnely not somethign we have to rush into
17:47:53 bauzas I have some concerns about it and I need to be convinced that nova wouldn't stop supporting exotic kernels just because of that
17:48:17 sean-k-mooney kind of like being secure by default i feel we shoudl try to be energy effiect by default
17:48:36 bauzas sure, and that makes sense
17:48:39 sean-k-mooney bauzas: well you could alwasy trun it off or we coudl try and detect it
17:48:49 bauzas we should even
17:48:58 sean-k-mooney prehasp we woudl intoduce an auto value in the future
17:49:10 bauzas detecting whether you can disable them or not at startup
17:49:21 sean-k-mooney ya
17:49:23 bauzas yeah, this sounds a right way
17:49:26 bauzas the auto thing
17:49:39 sean-k-mooney so if mede it a tri state true,false,auto
17:49:44 sean-k-mooney and then did the detection
17:49:51 sean-k-mooney that would be the best of both worlds
17:50:08 sean-k-mooney and it solves the ux problem but i also agree that would not be backportable
17:50:10 bauzas yeah, and this would convince me of opting-out this
17:50:25 bauzas provided the autodetect
17:51:14 sean-k-mooney do we ant to wait to disucss this with gibi tomorrow before proceeding with the current patch
17:54:33 bauzas this is additive
17:54:40 bauzas and as you said, not backportable
19:37:56 opendevreview Andriy Kurilin proposed openstack/python-novaclient master: Disable NEUTRON_ENFORCE_SCOPE at function job https://review.opendev.org/c/openstack/python-novaclient/+/901621
20:41:56 opendevreview Elod Illes proposed openstack/nova stable/yoga: [stable-only] Remove nova-emulation from check pipeline of Yoga https://review.opendev.org/c/openstack/nova/+/901604
20:44:05 elodilles sean-k-mooney: i forgot about the [stable-only] tag /o\ so now i've moved the job to experimental pipeline as you originally wanted ^^^
21:06:06 opendevreview Artom Lifshitz proposed openstack/nova master: Allow live migrate paused instance when post copy is enabled https://review.opendev.org/c/openstack/nova/+/444517
21:09:41 artom melwitt, since you looked at it previously and sean-k-mooney now has a +2, can I bother you for https://review.opendev.org/c/openstack/nova/+/883682?
21:11:20 andreykurilin Hi folks! python-novaclient-functional job became broken after neutron-related change to devstack https://review.opendev.org/c/openstack/devstack/+/899306 . I have a fix to unblock novaclient’s CI - https://review.opendev.org/c/openstack/python-novaclient/+/901621 but IDK whether the issue should be addressed differently. The review is appreciated.
21:16:28 melwitt artom: sure, will look
#openstack-nova - 2023-11-22
01:14:20 opendevreview Artom Lifshitz proposed openstack/nova master: Allow live migrate paused instance when post copy is enabled https://review.opendev.org/c/openstack/nova/+/444517
07:55:33 opendevreview Merged openstack/nova master: Allow enabling cpu_power_management with 0 dedicated CPUs https://review.opendev.org/c/openstack/nova/+/901188
08:29:31 opendevreview likui proposed openstack/nova master: Add py311 in tox file https://review.opendev.org/c/openstack/nova/+/901587
08:38:10 opendevreview likui proposed openstack/nova master: Add py311 in tox file https://review.opendev.org/c/openstack/nova/+/901587
09:11:28 opendevreview Pierre Libeau proposed openstack/nova master: nova-condutor put instance in error state https://review.opendev.org/c/openstack/nova/+/901655
09:22:16 opendevreview Balazs Gibizer proposed openstack/nova stable/2023.2: Do not manage CPU0's state https://review.opendev.org/c/openstack/nova/+/901566
09:22:39 opendevreview Balazs Gibizer proposed openstack/nova stable/2023.1: Do not manage CPU0's state https://review.opendev.org/c/openstack/nova/+/901567
09:24:21 gibi elodilles bauzas: ^^ power management bugfix backport ^^
09:25:14 gibi bauzas: this is a differnt bugfix
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 tkajinam I agree
09:16:37 bauzas that's why we have PTIs that continue to support old OS releases during 2 SLURP cadences
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

Earlier   Later