| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-21 | |||
| 17:06:43 | sean-k-mooney | it was deferd form the orgianl spec because we need libvirt to be modifed to enable this | |
| 17:06:45 | bauzas | I'm fine with approving it as specless but telling them to create a spec if during the implementation reviews we find some design concerns | |
| 17:07:02 | sean-k-mooney | well its actully more or less ready to merge | |
| 17:07:18 | sean-k-mooney | i have one nit and wanted to answer this question before +2ing it | |
| 17:07:21 | bauzas | given the change is already there, it's fine to review it now and ask for a spec if really needed | |
| 17:07:26 | sean-k-mooney | and stephenfin previously +2'd it | |
| 17:07:31 | bauzas | they wouldn't be impacted by the spec freeze | |
| 17:07:35 | bauzas | which is later | |
| 17:07:51 | bauzas | any controversial opinions on it being specless ? | |
| 17:08:15 | bauzas | looks not | |
| 17:08:29 | bauzas | we'll need tkajinam to create a blueprint | |
| 17:08:33 | sean-k-mooney | ok lets ask tkajinam to file a specless blueprint for this then and review it as normal once done | |
| 17:08:38 | sean-k-mooney | ya | |
| 17:08:42 | sean-k-mooney | ok that was it | |
| 17:08:45 | gibi | look OK to me | |
| 17:08:52 | bauzas | #agreed https://review.opendev.org/c/openstack/nova/+/899381 could be specless | |
| 17:09:21 | bauzas | #action tkajinam to create a blueprint and report it to bauzas so that he can late-approve it given above ^$ | |
| 17:09:33 | bauzas | okay, we're definitely overlate | |
| 17:09:40 | bauzas | really sorry about that | |
| 17:09:42 | bauzas | thanks all | |
| 17:09:46 | bauzas | #endmeeting | |
| 17:09:47 | opendevmeet | Meeting ended Tue Nov 21 17:09:46 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:09:47 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.html | |
| 17:09:47 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.txt | |
| 17:09:47 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-11-21-16.00.log.html | |
| 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 | |