| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-10-26 | |||
| 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 | |
| 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 | sean-k-mooney | but ok you could | |
| 14:28:58 | bauzas | correct, but I guess cpu online state can be independent | |
| 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 | bauzas | true, that was my current concerns | |
| 14:29:38 | sean-k-mooney | or zvm | |
| 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 | |
| 14:33:25 | bauzas | :) | |
| 14:34:04 | sean-k-mooney | i know we will never get around to doing this but some day i would like to split up driver.py | |
| 14:34:28 | sean-k-mooney | 10k loc is excessive | |
| 14:37:09 | bauzas | don't (git) blame me :) | |
| 14:54:12 | Uggla | agree driver.py is a bit long. ;) | |
| #openstack-nova - 2022-10-27 | |||
| 02:26:00 | opendevreview | melanie witt proposed openstack/nova master: Add mock to avoid loading guestfs in unit test https://review.opendev.org/c/openstack/nova/+/862769 | |
| 08:12:49 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: api: extend evacuate instance to support target state https://review.opendev.org/c/openstack/nova/+/858384 | |
| 08:12:49 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: compute: enhance compute evacuate instance to support target state https://review.opendev.org/c/openstack/nova/+/858383 | |
| 08:19:40 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova-specs master: spec: allowing target state for evacuate https://review.opendev.org/c/openstack/nova-specs/+/857838 | |
| 08:56:51 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reproduce PCI pool filtering bug https://review.opendev.org/c/openstack/nova/+/855649 | |
| 08:56:52 | opendevreview | Balazs Gibizer proposed openstack/nova master: Show candidate combinatorial explosion by dev number https://review.opendev.org/c/openstack/nova/+/855885 | |
| 08:56:52 | opendevreview | Balazs Gibizer proposed openstack/nova master: Strictly follow placement allocation during PCI claim https://review.opendev.org/c/openstack/nova/+/855650 | |
| 09:01:52 | gibi | bauzas: a procedural question. We have the RFE bug filed for the port route metric support https://bugs.launchpad.net/nova/+bug/1994137 it is a whislist so that part is OK. Should I simply set it to Triaged or we want to discuss it in the next meeting before I set Triaged? | |
| 09:02:18 | bauzas | gibi: no, we agreed on it so Triage it directly ;) | |