| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-21 | |||
| 17:41:21 | bauzas | and when I wrote the feature, I thought it was errorprone to tell "I want my cores to be power managed" if I wasn't providing dedicated cores | |
| 17:42:00 | bauzas | but I don't want to debate for so long about that, so let's ship it | |
| 17:42:02 | sean-k-mooney | the temp knob is hte cpu_dedicated_set (the quantiy of cpus) but i get your perspective too | |
| 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 | |