Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-11-21
17:09:53 elodilles thanks o/
17:10:10 bauzas fwiesel: grandchild: I appreciate your efforts, ping me anytime
17:10:26 fwiesel bauzas: thanks for the offer
17:10:33 elodilles sean-k-mooney: here is the patch about the nova-emulation job removal: https://review.opendev.org/c/openstack/nova/+/901604
17:10:57 sean-k-mooney elodilles: i had one locally too but happy to go with yours
17:11:12 elodilles sean-k-mooney: thx :)
17:11:20 sean-k-mooney i was goign to move it to experimental but im fine to jsut drop it
17:11:23 bauzas gibi: I don't want to be pedantic but I don't want https://review.opendev.org/c/openstack/nova/+/901188 to be a bugfix
17:11:33 sean-k-mooney if someone wants to try and fix it they can just add it back in there patch
17:12:07 elodilles sean-k-mooney: it still remains in the periodic-weekly pipeline at least
17:15:38 sean-k-mooney since peoepls are not reviwign the vmware removal patch can we try and land teh codespell seriese sooner rather then later https://review.opendev.org/c/openstack/nova/+/897092/1
17:21:15 gibi bauzas: I still consider that as a UX bug.
17:21:53 bauzas gibi: we wrote in the spec, I quote :
17:22:04 bauzas "This is the operator’s responsibility to verify that the OS kernel is recent enough to support CPU core tuning and that those CPU cores have their governors supporting both the performance and the powersave profiles."
17:22:59 bauzas if we magically make the feature opt-out, then we leave operators responsible of ensuring that their kernel can support cpu offline
17:23:03 gibi I don't see how that implies that the feature cannot be enabled with zero PCPUs and expect to do nothing
17:23:24 gibi bauzas: I'm not changing the default of the flag. It is still opt in
17:23:40 gibi the operator needs to explicitly enable the feature
17:23:59 gibi with [libvirt]cpu_power_management
17:24:03 gibi with [libvirt]cpu_power_management = True
17:25:20 bauzas touché
17:25:50 gibi what changes is that the operator can enable [libvirt]cpu_power_management = True before decides about the PCPU list of the given host
17:26:24 bauzas I mixed different conversations, one being not public
17:26:30 gibi this allows to enable [libvirt]cpu_power_management globally in a cloud in a deployment engine, and set PCPU config on the hypervisor independetly later
17:27:32 bauzas gibi: given the latter requires a nova-compute restart, I don't really see the benefits of enabling the former before, except if you have a deployment tool and you don't want your users to change that option
17:27:35 sean-k-mooney bauzas: are there specific risks or concerns you have with this change?
17:28:04 sean-k-mooney bauzas: i would eventully like to make [libvirt]cpu_power_management = True the default in nova by the way
17:28:09 bauzas sean-k-mooney: none for the master patch itself
17:28:17 gibi bauzas: there will be a single restart but there will be indedpendent decisions i) I need power management ii) I have a list of PCPUs used in a given hypervisor
17:28:18 bauzas hence my +1
17:28:29 sean-k-mooney but i dont want to require cpu_dedicated_set
17:28:55 sean-k-mooney ok so your concern is really just with framing this as a bug
17:29:07 gibi and if the decision #ii) result in an empty cpu_dedicated_set then I don't want to go back to decision i) as that is still valid
17:29:09 bauzas well, power management on non-dedicated cores is currently not something existing
17:29:28 sean-k-mooney right but this has nothign to do with that
17:29:29 bauzas sean-k-mooney: this is correct, as I wrote in both gerrit and here
17:29:37 gibi true, but power management on zero PCPUs actually work
17:29:48 gibi and help keeping the two configuration decision independent
17:30:15 bauzas if we were enabling power management on shared cores, surely we would make those options independent
17:30:20 gibi take my space heater example
17:30:43 gibi the on/off button and the temp knob are independent decisions
17:30:45 sean-k-mooney if we were to enabel it on shared cpus we woudl have to only supprot the governer policy
17:30:55 sean-k-mooney we coudl not supprot the cpu state policy
17:31:09 sean-k-mooney but even then i would expect new config optiosn for the cpu share set
17:31:17 gibi I don't want to alway use the on/off button when my room becomes cold. I want to rely on the combination of the two config to dyanmically heat my room
17:31:21 sean-k-mooney im not sure we will add that funcitonaltiy
17:31:31 sean-k-mooney at least right now i dont see a uescase to do that
17:32:51 bauzas you know what ? I'll stop
17:34:26 gibi I stop too. See you tomorrow
17:35:14 bauzas I sent it to... wait, actually nothing
17:35:20 bauzas the check pipeline failed
17:35:40 bauzas but I added a label called 'Workflow +1'
17:35:42 bauzas fwiw
17:36:02 gibi bauzas: thanks
17:40:29 bauzas (fwiw, the analogy with a room heater seems wrong to me : the on/off button seems to me the opt-in flag about power management, and the temp knob is the strategy)
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

Earlier   Later