| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-10-25 | |||
| 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 | |
| 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 | |
| 14:16:27 | bauzas | cloud, my ass | |
| 14:16:40 | sean-k-mooney | and variation on live resize ectra often come up so thats why im sensitive to this nameing | |
| 14:16:40 | bauzas | we call it 'resize" | |
| 14:16:44 | frickler | sean-k-mooney: o.k., so technically that should be very easy then. just a question of how much coordination/common policy is wanted | |
| 14:17:07 | bauzas | sean-k-mooney: yup, I understand your valid concern, let's not nitpick it | |
| 14:17:37 | bauzas | sean-k-mooney: but for your customer not understanding the cloud principles, please also tell him to rephrase correctly | |
| 14:17:38 | sean-k-mooney | frickler: we might port some thing by hand if we need too but if we did i would want to treat it as a bug scrub exersize | |
| 14:18:16 | sean-k-mooney | we have less then 30 stories for placment i think total | |
| 14:18:35 | sean-k-mooney | + a couple for osc-placment plugin | |
| 14:18:50 | sean-k-mooney | so thats the other reason im not too worried about tooling | |
| 14:18:56 | sean-k-mooney | other project are proably not as lucky | |
| 14:19:25 | frickler | sean-k-mooney: that sounds manageable indeed and combining with scrubbing is a good idea, too | |
| 14:21:30 | sean-k-mooney | bauzas: well i just tool them not until at least osp 20+ | |
| 14:21:49 | sean-k-mooney | for non redhattser we released 17 recently :) | |
| 14:22:08 | sean-k-mooney | in ohter words if we get to it it wont be for a few years | |
| 14:22:09 | bauzas | sean-k-mooney: that's a long ask for live-resize | |
| 14:22:27 | bauzas | my only concern is not whether we should do it, but about the term too | |
| 14:23:04 | bauzas | 'can I attach a new cpu live to a running guest" is an acceptable QEMU feature, but this is horribly not cloudy | |
| 14:23:29 | bauzas | 'can I resize my running instance with a new flavor so I could have one more CPU' is the correct way to ask | |
| 14:23:38 | sean-k-mooney | ya libvirt and qemu can do it althogh you need to know the maxium number of cpu you might have ahead of time | |
| 14:24:37 | sean-k-mooney | but agree on the not very cloudy aspect | |
| 14:24:47 | bauzas | I mean, if we nitpick on the hotplug term (that QEMU just hijacked), then I can nitpick on the customer ask saying he doesn't know what a cloud is, then :) | |
| 14:25:24 | sean-k-mooney | well hotplug did not come form the cpu side it came from pci devices orgianly as far as im aware | |
| 14:25:31 | sean-k-mooney | but more relevent topic | |