| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-21 | |||
| 17:03:53 | bauzas | #action bauzas to create a meeting topic in order to discuss the efforts | |
| 17:03:55 | grandchild | ftr: jkulik is not in the office today, but also in the mix from us :) | |
| 17:04:03 | bauzas | sure | |
| 17:04:20 | bauzas | sean-k-mooney: I appreciate your understanding about the deferral | |
| 17:04:35 | sean-k-mooney | its ok ill ask ye to review other patches instead :P | |
| 17:04:38 | grandchild | sean-k-mooney: we do too! thanks :) | |
| 17:04:38 | bauzas | grandchild: fwiesel: I aslo appreciate your efforts in trying to bond with us | |
| 17:04:53 | bauzas | let it be going | |
| 17:05:02 | bauzas | and we'll see during the next weeks how things go | |
| 17:05:12 | bauzas | we're waaaay overlate | |
| 17:05:15 | sean-k-mooney | before we finish the meeting | |
| 17:05:20 | sean-k-mooney | i did have a topic for this week | |
| 17:05:22 | bauzas | shoot, but quick | |
| 17:05:25 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/899381 | |
| 17:05:36 | sean-k-mooney | basically does that need a specless blueprint or bug | |
| 17:06:02 | sean-k-mooney | tl;dr libvirt can now tell use how many sev instnace we can create | |
| 17:06:09 | sean-k-mooney | we have a optional config option to do that | |
| 17:06:25 | sean-k-mooney | this patch will just auto detect the amount and report it | |
| 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 | |