| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-10-25 | |||
| 16:15:15 | bauzas | #topic Stable Branches | |
| 16:15:20 | bauzas | gibi: ah cool to know | |
| 16:15:24 | bauzas | elodilles: your turn | |
| 16:15:31 | elodilles | thanks | |
| 16:15:40 | elodilles | so as we discussed at PTG | |
| 16:15:43 | elodilles | #info stein, rocky and queens EOL'ing patch was proposed: https://review.opendev.org/862520 + mail was sent to ML https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030980.html | |
| 16:15:54 | elodilles | and the status: | |
| 16:15:56 | elodilles | #info from stable/zed back till stable/ussuri branches' gates should be OK | |
| 16:15:59 | elodilles | #info stable/train must have been fixed ( https://review.opendev.org/c/openstack/devstack-gate/+/860961 ) | |
| 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 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-10-25-16.00.log.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 | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-10-25-16.00.html | |
| 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 | bauzas | #endmeeting | |
| 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 | elodilles | (bauzas: i did the EOL'ing with release tools, yes ;)) | |
| 16:20:16 | bauzas | that's the name of the meetup, I'm scared in advance | |
| 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: Handle zero pinned CPU in a cell with mixed policy https://review.opendev.org/c/openstack/nova/+/862687 | |
| 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: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 | sean-k-mooney | i dont want to confust this with hotpluging cpus in the guest | |
| 14:09:32 | bauzas | sean-k-mooney: I know, but this is the official terminology, right? | |
| 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 | sean-k-mooney | that why i prefer cpu-online-state-management or similr | |
| 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: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 | |