| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-10-25 | |||
| 16:16:09 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:16:11 | bauzas | I'm OK with the EOL patch | |
| 16:16:24 | elodilles | bauzas: cool \o/ | |
| 16:16:34 | bauzas | I'll review the hashes but given you probably made it with the tooling in place, I don't expect problems | |
| 16:16:38 | elodilles | let's do the formal waiting and then we can merge it | |
| 16:16:47 | elodilles | and delete those old broken branches :'( | |
| 16:16:48 | bauzas | and then I'll set the PTL-approval | |
| 16:16:59 | elodilles | bauzas: ++ | |
| 16:17:10 | bauzas | elodilles: true, let's wait but I'll still send the signal I'm ok with the deletion | |
| 16:17:19 | bauzas | anything else to mention ? | |
| 16:17:24 | elodilles | nothing from me | |
| 16:17:28 | gibi | elodilles: thanks, that was quick | |
| 16:17:33 | elodilles | ++ | |
| 16:17:39 | bauzas | #topic Open discussion | |
| 16:17:44 | bauzas | nothing written | |
| 16:17:50 | bauzas | anything anyone ? | |
| 16:18:19 | bauzas | iirc, some actions were made at the PTG to propose specless blueprints at weekly meetings | |
| 16:18:36 | bauzas | I don't remember yet which blueprints and who, but we can arrange this later | |
| 16:18:47 | bauzas | oh the neutron thing | |
| 16:18:49 | bauzas | from sean-k-mooney | |
| 16:19:01 | bauzas | whether this was a bugfix or bluepritn | |
| 16:19:11 | bauzas | if you don't mind, let's punt this for next week | |
| 16:19:35 | bauzas | I don't hear screams | |
| 16:19:39 | bauzas | eventually... | |
| 16:19:44 | bauzas | thanks all, | |
| 16:19:47 | bauzas | #endmeeting | |
| 16:19:47 | opendevmeet | Meeting ended Tue Oct 25 16:19:47 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:19:47 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-10-25-16.00.html | |
| 16:19:47 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-10-25-16.00.txt | |
| 16:19:47 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-10-25-16.00.log.html | |
| 16:19:49 | sean-k-mooney | sure | |
| 16:19:54 | gibi | bauzas: thanks, have a nice meetup | |
| 16:19:55 | bauzas | this was as quick as I could | |
| 16:20:03 | bauzas | gibi: python horrow show | |
| 16:20:16 | bauzas | that's the name of the meetup, I'm scared in advance | |
| 16:20:16 | elodilles | (bauzas: i did the EOL'ing with release tools, yes ;)) | |
| 16:20:32 | elodilles | o/ | |
| 16:20:53 | gibi | bauzas: will they talk about nova there? ;) | |
| 16:32:02 | opendevreview | sean mooney proposed openstack/nova-specs master: add spec for fqdn in hostname https://review.opendev.org/c/openstack/nova-specs/+/862626 | |
| 16:32:45 | sean-k-mooney | artom: ^ there you go | |
| 17:00:27 | artom | sean-k-mooney, cheers! | |
| 17:00:40 | artom | dansmith, ^^ I'm bringing it to your attention now as early as possible :) | |
| 17:21:26 | dansmith | but it's not 0.9*cycle_length yet! | |
| 18:52:17 | artom | dansmith, I know, I'm capable of rudimentary learning and self-improvement! | |
| 18:52:34 | artom | I'm as flabbergasted at the concept as you are ;) | |
| #openstack-nova - 2022-10-26 | |||
| 08:07:20 | sahid | o/ technical detail regarding the new behavior for evacuate, wondering what kind of parameter for the API, any idea? | |
| 08:07:44 | sahid | s//what kind of parameter should I use | |
| 08:08:28 | sahid | currently I'm passing target_state={active|stop}, but I'm not sure if that sound right now | |
| 08:09:22 | sahid | even if I force it to stop for the new microversion | |
| 08:10:19 | sahid | perhaps, target_behavior={old, stop} | |
| 08:10:41 | sahid | sean-k-mooney: ^ in case that you have something in head | |
| 08:11:46 | sahid | or I can just keep target_state with {None, stop}, where None will be the old behavior and stop the new behavior, stop will be forced for new API | |
| 12:18:02 | sean-k-mooney | sahid: well with the old microverion you shoudl not pass target_state at all at the rpc layer it will default ot none | |
| 12:18:06 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce asym NUMA mixed CPU policy bug https://review.opendev.org/c/openstack/nova/+/862686 | |
| 12:18:06 | opendevreview | Balazs Gibizer proposed openstack/nova master: Handle zero pinned CPU in a cell with mixed policy https://review.opendev.org/c/openstack/nova/+/862687 | |
| 12:18:52 | sean-k-mooney | and then for the new microverion you can pass the flag it can be target_state="stop" | |
| 12:19:19 | sean-k-mooney | you shoudl not need to ever pass started or old | |
| 12:44:46 | sahid | sean-k-mooney: i see, so basically i kept the actual impl but update the REST API part + ofcourse some tests on compute API part | |
| 12:44:55 | sahid | s/kept/keep | |
| 12:44:59 | sean-k-mooney | yep | |
| 12:45:06 | sahid | let's make a try, thanks | |
| 12:45:14 | sean-k-mooney | 99% of what you have should not need to be changed | |
| 12:45:20 | sahid | ++ | |
| 13:47:47 | frickler | not sure if everyone is subscribed, discussion about the storyboard issue is now happening here https://lists.opendev.org/pipermail/service-discuss/2022-October/000370.html , sean-k-mooney has already given a good summary of UX issues | |
| 14:04:56 | sean-k-mooney | hopefully that wont derail things too much | |
| 14:06:41 | sean-k-mooney | frickler: while that discussion is happening im more then happy to hold of doing anything with placment ectra | |
| 14:07:53 | sean-k-mooney | bauzas: https://blueprints.launchpad.net/nova/+spec/libvirt-cpu-hotplug this is not hotplug | |
| 14:08:08 | sean-k-mooney | please do not use that terminology anywhere near this | |
| 14:08:15 | sean-k-mooney | even at teh kernel level that is incorrect | |
| 14:08:25 | bauzas | sean-k-mooney: well, https://www.kernel.org/doc/html/latest/core-api/cpu_hotplug.html seems the correct term | |
| 14:08:53 | sean-k-mooney | hotplug usussaly refer to addign or removing cpu pacakges | |
| 14:08:57 | sean-k-mooney | i.e. entire chips | |
| 14:09:09 | sean-k-mooney | not just onlineing/offlining indivuguale cores | |
| 14:09:10 | bauzas | and https://lwn.net/Articles/537570/ | |
| 14:09:32 | bauzas | sean-k-mooney: I know, but this is the official terminology, right? | |
| 14:09:32 | sean-k-mooney | i dont want to confust this with hotpluging cpus in the guest | |
| 14:09:51 | sean-k-mooney | its ambiguous in a nova context | |
| 14:10:01 | sean-k-mooney | if its the host or guest cpu that is hotplugged | |
| 14:10:09 | sean-k-mooney | which si why i strongly dislike using it here | |
| 14:10:38 | bauzas | https://www.qemu.org/docs/master/system/cpu-hotplug.html <= yup because qemu supersedes this term | |
| 14:10:42 | frickler | sean-k-mooney: given that nova is on LP and not considering changing that, reverting placement to LP too seems the only sane solution to me. by extension I also think that holds for any OpenStack project that is unlucky on storyboard. the question is who will invest in tooling to migrate issues back. or whether it is o.k. to just discard them | |
| 14:10:42 | sean-k-mooney | that why i prefer cpu-online-state-management or similr | |
| 14:11:21 | sean-k-mooney | frickler: well for placement i was proposing explictly not merging any of them back | |
| 14:11:56 | bauzas | sean-k-mooney: I understand your concern, I'll change it but in the spec, I'll explain this is a cpu hotplug from the kernel, not for QEMU | |
| 14:12:20 | sean-k-mooney | bauzas: i could live with that but i think its still the wrong terminology to use | |
| 14:12:38 | sean-k-mooney | are managing the onlien state | |
| 14:12:39 | bauzas | sean-k-mooney: ask the kernel team to change it :p | |
| 14:12:58 | bauzas | because QEMU | |
| 14:13:01 | bauzas | they'd love this :p | |
| 14:13:07 | sean-k-mooney | we are doing echo 0 > /sys/devices/system/cpu/cpu4/online | |
| 14:13:22 | sean-k-mooney | its not wrong to refer to it as online state managemnt | |
| 14:13:40 | bauzas | sure, hence me renaming the blueprint name | |
| 14:14:03 | sean-k-mooney | https://www.kernel.org/doc/html/latest/core-api/cpu_hotplug.html#cpu-online-offline-operations | |
| 14:14:10 | bauzas | but as I said, unless I misunderstand, this is based on the CPU hotplug feature named like this in the kernel, right? | |
| 14:14:12 | sean-k-mooney | the also use the online offline termonology | |
| 14:14:50 | sean-k-mooney | it uses the same machinary the build for adding and removing phsyical cpu pakcages to orchstrate turing on and off indivugual hyperthread/cores yes | |
| 14:14:54 | bauzas | sean-k-mooney: true, again, I'm not opposed to the term change, I'll just explain in the spec what we refer by "online state management" | |
| 14:15:17 | bauzas | wfy ? | |
| 14:15:24 | sean-k-mooney | yep works for me | |
| 14:16:04 | sean-k-mooney | we had another request for "virtical scaleing" form a custoemr i.e. hotpluging a cpu to a vm based on load already this week | |