| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-10-10 | |||
| 16:31:57 | bauzas | I'll tell this to sahid tomorrow | |
| 16:32:12 | bauzas | and he could explain why he still wants to use filters | |
| 16:32:20 | bauzas | (IMHO like I said, backports) | |
| 16:32:39 | bauzas | do all agree ? | |
| 16:32:44 | sean-k-mooney | backports are a downstream problem | |
| 16:33:01 | bauzas | sure, but this is easier with a python module like a filter, right?. | |
| 16:33:03 | sean-k-mooney | that is not a good reason to extend it upstream unless its useful upstream | |
| 16:33:21 | bauzas | sure, we need to discuss the usecases | |
| 16:33:33 | bauzas | but I'm not in favor of removing every single filter we have | |
| 16:33:44 | dansmith | agree | |
| 16:33:44 | bauzas | some operators still run filters on their choices | |
| 16:34:17 | bauzas | anyway, let's punt this until PTG or when sahid can join us | |
| 16:34:26 | dansmith | we have the prefilter for isolation, which uses placement's aggregates to do some isolation, but I'll have to revisit my understanding of the differences | |
| 16:34:31 | bauzas | #agreed defer this agreement to the next PTG | |
| 16:34:49 | bauzas | I'll add a topic in the PTG etherpad | |
| 16:34:55 | sean-k-mooney | dansmith: we deveoped that prefilter to eventurlly remove this one | |
| 16:36:07 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-req-filter.html#proposed-change | |
| 16:36:43 | bauzas | sean-k-mooney: well, for CPUFilter, I totally agree with removing it | |
| 16:36:47 | sean-k-mooney | this was the first prefilter that you wote many moons ago | |
| 16:37:24 | bauzas | I'm just saying that for non-allocatable filters (placing things) we may leave those if those are cheap to maintain | |
| 16:37:41 | sean-k-mooney | right but this filter is know to be problematic | |
| 16:37:42 | bauzas | because this is a python module and not another SQL query | |
| 16:37:54 | sean-k-mooney | so i realy dont think this is a good example ot extned | |
| 16:37:55 | dansmith | sean-k-mooney: I know, but I think there were limitations | |
| 16:38:18 | bauzas | anyway, we punted the potential agreement to the next PTG | |
| 16:38:21 | dansmith | I thought we agreed to punt until PTG ? | |
| 16:38:22 | dansmith | yeah | |
| 16:38:30 | bauzas | so let's stop for now | |
| 16:38:40 | sean-k-mooney | sure | |
| 16:38:40 | bauzas | and I'll give you all extra 20 mins of your time | |
| 16:38:42 | bauzas | thanks all | |
| 16:38:52 | bauzas | any other item before we close ? | |
| 16:39:07 | sean-k-mooney | i just wanted to highlight i reporposed the healtcheck spec https://review.opendev.org/c/openstack/nova-specs/+/897225 | |
| 16:39:16 | bauzas | oh right, I've seen it | |
| 16:39:20 | sean-k-mooney | so if we can reappove that it would be good | |
| 16:39:22 | bauzas | I just need to look at it | |
| 16:39:25 | sean-k-mooney | ack | |
| 16:39:41 | sean-k-mooney | thats all from me | |
| 16:39:43 | bauzas | tuesdays are usually upstream days for me, but I was vamped into some crazy internal thing | |
| 16:39:57 | bauzas | anyway, ending now | |
| 16:40:00 | bauzas | thanks all | |
| 16:40:04 | bauzas | #endmeeting | |
| 16:40:04 | opendevmeet | Meeting ended Tue Oct 10 16:40:04 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:40:04 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-10-10-16.00.html | |
| 16:40:04 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-10-10-16.00.txt | |
| 16:40:04 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-10-10-16.00.log.html | |
| 16:40:33 | sean-k-mooney | bauzas: if your looking at repoposals then https://review.opendev.org/c/openstack/nova-specs/+/895924 would be alos nice to look at | |
| 16:40:46 | bauzas | yeah I need to do reviews | |
| 16:40:59 | bauzas | my gerrit nova-specs dashboard misses me | |
| 16:42:13 | opendevreview | Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708 | |
| 16:42:24 | dansmith | okay locally mtty.ko gets built and inserted during devstack | |
| 16:43:58 | bauzas | <3 | |
| 16:44:47 | bauzas | if I have time tomorrow, I'll work on a nova WIP to change the libvirt driver to use a specific 'virtual' device for mtty | |
| 16:45:02 | bauzas | so we shall be able to test | |
| 16:58:34 | opendevreview | Dan Smith proposed openstack/nova master: WIP: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708 | |
| 17:21:36 | dansmith | 2023-10-10 17:19:30.033749 | controller | ++ /opt/stack/nova/devstack/lib/mdev_samples:compile_mdev_samples:28 : grep mdev | |
| 17:21:36 | dansmith | 2023-10-10 17:19:30.055298 | controller | mdev 28672 1 mtty | |
| 17:21:47 | dansmith | \o/ | |
| 17:42:02 | sean-k-mooney | cool | |
| 17:42:23 | sean-k-mooney | we dont do a virsh nodedev-list in the ci logs do we | |
| 17:42:44 | sean-k-mooney | i woudl assume not | |
| 17:54:07 | dansmith | idk, but I just ran that locally and I don't see any mdev stuff in there | |
| 17:54:27 | sean-k-mooney | i think they only show up when you create one | |
| 17:54:33 | sean-k-mooney | its also cached when libvirt starts | |
| 17:54:49 | sean-k-mooney | so if it starts before the module is loaded that could be an issue | |
| 17:54:56 | sean-k-mooney | restarting libvirt clears the cache | |
| 17:56:21 | sean-k-mooney | can you try " echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > \ | |
| 17:56:24 | sean-k-mooney | /sys/devices/virtual/mtty/mtty/mdev_supported_types/mtty-2/creat""" | |
| 17:57:27 | dansmith | mdev_83b8f4f2_509f_382f_3c1e_e6bfe0fa1001_mtty | |
| 17:57:33 | sean-k-mooney | cool | |
| 17:57:33 | dansmith | looks like it works | |
| 17:57:50 | sean-k-mooney | so nova has two modes of opertation | |
| 17:57:58 | sean-k-mooney | you can either precreate the mdevs and it will use them | |
| 17:58:06 | sean-k-mooney | or it will create tehm if you dont | |
| 17:58:38 | sean-k-mooney | but ya from a qemu/libvirt point of view i think that means its workign | |
| 17:58:51 | dansmith | sweert | |
| 18:03:43 | sean-k-mooney | oh right it was out of tree.. | |
| 18:07:05 | sean-k-mooney | for what its worht this is how you boot a vm in nova with hardware offloaded networkign using mdev before that is merged in qemu/libvirt/the kernel https://github.com/openstack/nova/commit/13de00c20477189201f102499cc6451f47765c5c | |
| 18:10:43 | sean-k-mooney | that is not relevent beyond the fact i was checkign how we configured the mdevs and vf via the devstack plugin | |
| 18:10:45 | sean-k-mooney | https://github.com/intel-orchestration-software/networking-vhost-vfio/blob/master/devstack/libs/vhost-vfio#L367-L393 | |
| 18:11:12 | sean-k-mooney | so we just allocated the vf on the defice and created the mdevs dymically in nova | |
| 18:11:33 | sean-k-mooney | so not really relevent in this case since there are no vfs to allcoate | |
| 18:22:15 | tobias-urdin | any good idea's on how one should handle cputune.shares issues on stable releases? https://bugs.launchpad.net/nova/+bug/1978489 – last comment in https://gitlab.com/libvirt/libvirt/-/issues/161 aged well "...I think this problematic change is only now starting to hit people" oh yes it will :) | |
| 18:22:15 | tobias-urdin | any good idea's on how one should handle cputune.shares issues on stable releases? https://bugs.launchpad.net/nova/+bug/1978489 – last comment in https://gitlab.com/libvirt/libvirt/-/issues/161 aged well "...I think this problematic change is only now starting to hit people" oh yes it will :) | |
| 18:45:25 | sean-k-mooney | we partly fixed this | |
| 18:45:38 | sean-k-mooney | we stopped generating implcit cpu shares in zed i belvie | |
| 18:45:50 | sean-k-mooney | and we basically say dont use the explit ones | |
| 18:46:00 | sean-k-mooney | we have not removed/depreated the feature entirly | |
| 18:46:14 | sean-k-mooney | simply because we have never done that before | |
| 18:46:41 | sean-k-mooney | but perfonslly i would fix it by deprecateing them on master for caracal and delete the feature in D | |
| 18:46:52 | sean-k-mooney | tobias-urdin: proably not waht you want to hear so the more helpful answer is | |
| 18:47:42 | sean-k-mooney | you need to reize today before you upgrade | |
| 18:47:56 | sean-k-mooney | we could also add a nova manage command liek https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L3211 | |
| 18:48:09 | sean-k-mooney | to allow updating the embded flavor extra specs | |
| 18:48:20 | sean-k-mooney | that not negerally safe but in this case it is | |
| 19:05:39 | tobias-urdin | thanks, yeah it was an interesting read for sure and something i completely missed last year | |
| 19:06:28 | tobias-urdin | imo the approach taken in libvirt is pretty bad, im kinda sad it wasn't better handled at all in https://gitlab.com/libvirt/libvirt/-/issues/161 either | |
| 19:07:25 | tobias-urdin | fortunately is that we dont set it as extra specs but we do however have large instances that will be impacted just based on the cpu.shares value being greater than the limit there | |
| 19:07:53 | tobias-urdin | so for us on yoga i guess i'll just have to carry that patch until i'm on zed, shouldn't be that long | |
| 19:11:53 | tobias-urdin | im just a little bit scared about the impact for large instances removing that entirely but i guess i dont have a choice, i felt like scaling the value for cgroupv2 in cputune.shares and introducing a new cputune.weight was more elegant, anyway | |