| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-10-26 | |||
| 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 | |
| 14:30:29 | bauzas | then, nevermind | |
| 14:30:38 | bauzas | I'll just create a package under libvirt | |
| 14:30:41 | bauzas | libvirt.cpu | |
| 14:30:51 | sean-k-mooney | ack | |
| 14:31:00 | sean-k-mooney | that or put the function into host.py | |
| 14:31:08 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py | |
| 14:31:15 | sean-k-mooney | but its own thing proably is simpler | |
| 14:31:20 | sean-k-mooney | well cleaner | |
| 14:31:34 | bauzas | well, the host module is mostly for talking to the host libvirt API right? | |
| 14:31:43 | sean-k-mooney | mostly but not entirly | |
| 14:31:46 | bauzas | true | |
| 14:32:00 | bauzas | I just want to have some interface | |
| 14:32:11 | sean-k-mooney | we lookup the firmware files for uefi there and i think some vtpm stuff | |
| 14:32:13 | bauzas | but I need to think it more | |
| 14:32:26 | sean-k-mooney | honestly poc it however you feel is best | |
| 14:32:45 | sean-k-mooney | we can debttate it later but i think under the libvirt driver somewhere is the right approch | |
| 14:32:52 | bauzas | tru | |
| 14:32:54 | bauzas | true* | |
| 14:33:03 | sean-k-mooney | beyond that as long as you dont just put it in driver.py im more or less ok with it | |
| 14:33:09 | sean-k-mooney | driver.py is already too big | |