| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-10-26 | |||
| 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 | |
| 14:16:27 | bauzas | cloud, my ass | |
| 14:16:40 | bauzas | we call it 'resize" | |
| 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: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 | |
| 14:25:44 | sean-k-mooney | can you add me to the spec when you push it or ping me | |
| 14:26:00 | sean-k-mooney | ill add it to my review list | |
| 14:26:24 | bauzas | sure | |
| 14:26:32 | bauzas | I'm now working on the prototype | |
| 14:26:53 | bauzas | I was considering a new package structure in hardware | |
| 14:27:27 | sean-k-mooney | you mean creating a folder in the libvirt driver for it? | |
| 14:27:54 | sean-k-mooney | https://github.com/openstack/nova/tree/master/nova/virt/libvirt | |
| 14:27:59 | sean-k-mooney | becide storage and volume | |
| 14:28:09 | sean-k-mooney | if so that proably makes sense yes | |
| 14:28:16 | bauzas | no, turning hardware to be a package | |
| 14:28:21 | bauzas | not a single module | |
| 14:28:27 | bauzas | virt.hardware | |
| 14:28:35 | sean-k-mooney | in theory that is ment to work across drivers | |
| 14:28:36 | bauzas | so we could have virt.hardware.cpu | |
| 14:28:49 | sean-k-mooney | as in parts of it are used by not libvirt | |
| 14:28:58 | bauzas | correct, but I guess cpu online state can be independent | |
| 14:28:58 | sean-k-mooney | but ok you could | |
| 14:29:14 | sean-k-mooney | well it woudl work on any linux | |
| 14:29:15 | bauzas | that tho relies on the kernel and sysds | |
| 14:29:19 | sean-k-mooney | so maybe powervm | |
| 14:29:38 | sean-k-mooney | or zvm | |
| 14:29:38 | bauzas | true, that was my current concerns | |
| 14:30:03 | sean-k-mooney | we dont really have any other driver that woudl use it anymore | |
| 14:30:18 | bauzas | well, actually, you're right, and this would confuse people | |
| 14:30:25 | bauzas | we agreed at the PTG to have this libvirt-specifc | |