| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-10-13 | |||
| 13:36:28 | bauzas | but let's merge it | |
| 13:36:41 | dansmith | have we asked the libvirt guys to be sure? | |
| 13:36:42 | bauzas | and we could just revert it if we find eventually that it's not able | |
| 13:36:47 | bauzas | dansmith: not yet | |
| 13:36:56 | bauzas | I had a lot of discussions with them | |
| 13:37:02 | bauzas | but not for this :) | |
| 13:37:02 | dansmith | either way, to me it really seems like doing what we need to do to be able to use these as our test fixture is worthwhile | |
| 13:45:37 | sean-k-mooney | bauzas: to me the libvirt gap is somethign we cna entrily work around in nova | |
| 13:46:12 | sean-k-mooney | dansmith: i dont disagree but i have provposed adding this exact supprot before and supproting the netdev sim for vdpa and bauzas has object during spec review | |
| 13:46:37 | sean-k-mooney | i have previously been tool we are not ment to add suprpot for emulated device just for testing | |
| 13:46:54 | sean-k-mooney | but i would like to do that personally | |
| 13:47:08 | bauzas | sean-k-mooney: if we want to persist mdevs, you know that we will need to no longer call sysfs and directly call libvirt | |
| 13:47:31 | bauzas | so if we need to go to the other way due to mtty, it would be bizarre | |
| 13:48:01 | sean-k-mooney | bauzas: yes im aware we woudl need to call libvirt to create mdevs | |
| 13:48:02 | bauzas | even if that's not for the same call | |
| 13:48:17 | sean-k-mooney | but right now your calling sysfs to create tehm | |
| 13:48:21 | bauzas | one is for getting mdev capable devices, the other one is for calling to create a mdev | |
| 13:48:24 | sean-k-mooney | but libvirt to ask about capasity | |
| 13:48:29 | sean-k-mooney | so its already split brained | |
| 13:48:30 | bauzas | yes | |
| 13:48:45 | bauzas | so, we would need to change both... | |
| 13:49:30 | sean-k-mooney | so what i would do is if we provide a real pci adress in the config | |
| 13:49:39 | sean-k-mooney | then we would just get the capstiy form libvirt | |
| 13:49:56 | sean-k-mooney | if not we shoudl get it form sysfs since its a virtual device | |
| 13:50:11 | sean-k-mooney | adn use libvirt to alwasy create mdevs instead of sysfs | |
| 13:51:21 | sean-k-mooney | we can specify that the value for the pci adress for virtual devices is the subpath under /sys/devices/virtual if you want too | |
| 13:51:50 | sean-k-mooney | so it woudl be pci_adddress=mtty/mtty or mdpy/mdpy if you want or just have a seperte config | |
| 13:51:59 | sean-k-mooney | there are lots of way to make that cleaner | |
| 13:52:54 | bauzas | sean-k-mooney: that's what I wrote in my mtty patch | |
| 13:53:08 | sean-k-mooney | i.e. device_path /sys/devices/virtual/mtty/mtty or device_path=mtty/mtty | |
| 13:53:10 | bauzas | if you pass "mtty" as a pci device, nova doesn't check the pci address | |
| 13:53:35 | sean-k-mooney | sure but i dont thinkg we should pass mtty it shodl be mtty/mtty | |
| 13:53:42 | bauzas | ok, so you would add a conditional, I see | |
| 13:53:50 | sean-k-mooney | yes | |
| 13:53:54 | sean-k-mooney | you basicaly alrady have | |
| 13:53:56 | dansmith | sean-k-mooney: not sure if "but I would like to do that" was inverted or not, but I think designing a feature with fake fixtures in mind, or designing those fixtures along with the feature is the best plan | |
| 13:54:03 | bauzas | sean-k-mooney : have you seen my uploaded mtty patch ? | |
| 13:54:15 | dansmith | and if we have fake mdev devices that need a little extra care, it's worth us designing *for* those as much as the real hardware where reasonable, IMHO | |
| 13:54:27 | bauzas | the workaround is just to precreate the mdevs :) | |
| 13:54:27 | sean-k-mooney | dansmith: i would like to supprot the virtual device by design | |
| 13:54:37 | sean-k-mooney | i.e. design for testablity and funcitonlity | |
| 13:54:40 | sean-k-mooney | not just funcitonlity | |
| 13:55:03 | sean-k-mooney | bauzas: that is fine too if it works | |
| 13:55:11 | bauzas | I don't know what happened to me when I started writing that code but I regret every single day that nova supports creating mdevs on the fly | |
| 13:55:48 | sean-k-mooney | the creation isnt relaly the problem. the fact we dont store them in the db is where a lot of the pain comse form | |
| 13:55:58 | sean-k-mooney | since we cant recreate them as needed with the same values | |
| 13:56:48 | sean-k-mooney | bauzas: so i guess for now to get soemthign workign we can precreate them in the ci job | |
| 13:57:16 | bauzas | I'm just out of band for now | |
| 13:57:17 | sean-k-mooney | but i think we can just make this work even without that with minimal extra complexity | |
| 13:57:25 | bauzas | the customer issue went back | |
| 13:57:49 | bauzas | and I also have a lot of back-and-forths internally with people afraid of the situation | |
| 13:58:13 | bauzas | so I basically punted to continue working on mtty for today | |
| 13:58:29 | bauzas | but last time I tried on my vm, mdev creation was working | |
| 13:58:43 | bauzas | what I haven't tried yet was to download my patch and test it | |
| 13:58:50 | bauzas | with precreated mdevs | |
| 13:59:45 | dansmith | sean-k-mooney: ++ | |
| 14:00:29 | dansmith | honestly I think creating on the fly makes plenty of sense, | |
| 14:00:43 | dansmith | we just need a persistence mechanism, which is either libvirt or us | |
| 14:01:09 | sean-k-mooney | we can perssitee them in the resouce table without any db modification | |
| 14:01:13 | sean-k-mooney | if we want too | |
| 14:01:17 | sean-k-mooney | or have libvirt do it | |
| 14:01:25 | dansmith | I don't know that not being able to have libvirt persist mtty is really a problem.. like if that works for real devices and the deal is you just can restart a dev box with mtty fake devices, that's not too bad | |
| 14:01:26 | sean-k-mooney | both work | |
| 14:01:53 | bauzas | the libvirt feature already exists | |
| 14:01:55 | bauzas | https://libvirt.org/drvnodedev.html#example-of-a-mediated-device | |
| 14:01:59 | sean-k-mooney | i know | |
| 14:02:08 | bauzas | let's just use it | |
| 14:02:11 | sean-k-mooney | which is why we want to use it. | |
| 14:02:23 | sean-k-mooney | but im just saying this is a very solvable problem | |
| 14:02:43 | bauzas | I'm not particulatly in favor of adding another datastructure in nova for something we can let the hypervisor handle | |
| 14:03:03 | bauzas | and yet again a sync problem between the hypervisor and us | |
| 14:03:19 | bauzas | (but that's MHO) | |
| 14:03:38 | bauzas | again, priorities matter and that's on my scope | |
| 14:03:53 | bauzas | I just have a limited 70hours bandwidth this week | |
| 14:04:00 | dansmith | yep, agree we should not build data structures if we don't have to | |
| 14:04:33 | sean-k-mooney | the reason we diding in the frist place was just because this was all ment to be tracked via placement | |
| 14:05:24 | sean-k-mooney | but we didnt actully impelmetnet it in such a way that would work since we have no encodign of which mdev was for which allocation | |
| 14:05:39 | sean-k-mooney | but sure sound like we have a short term adn medium path forward | |
| 14:05:51 | sean-k-mooney | shortterm just preacllocate the mdevs | |
| 14:05:54 | sean-k-mooney | in the job | |
| 14:06:15 | sean-k-mooney | medium term just make creation on the fly work with the fallback to reading /sys for aviablie_isntances | |
| 14:06:39 | sean-k-mooney | in either case this is next week us problem i assume | |
| 14:06:44 | bauzas | agreed with the plan | |
| 14:07:05 | bauzas | I just need hands on deck | |
| 14:07:08 | sean-k-mooney | we proceed with teh current devstack plugin and enhance it to do the other bits as we go | |
| 14:07:16 | sean-k-mooney | *shall we | |
| 14:07:24 | dansmith | bauzas: I know you | |
| 14:07:36 | dansmith | are not suggesting that we're barking orders without helping right? | |
| 14:08:11 | bauzas | no no | |
| 14:08:31 | bauzas | this is just that this puzzle is horribly overcomplicated and I'm just a man | |
| 14:09:05 | bauzas | and now the situation has been properly addressed and acked by above, I get many sollicitations :) | |
| 14:09:13 | bauzas | (which is eventually good) | |
| 14:09:31 | bauzas | so, yeah, taking one piece after the other | |
| 14:13:05 | sean-k-mooney | dansmith: oh you found out why the kvm kerenl fialed. ya if mdev was compiled out in that it makes total sense | |
| 14:13:43 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Forbid use_cow_images together with flat images_type https://review.opendev.org/c/openstack/nova/+/898229 | |
| 14:13:46 | sean-k-mooney | im pulling th trigger on the devstack plugin patch lets impove it in followups | |
| 14:15:56 | dansmith | sean-k-mooney: yep | |
| 16:25:21 | opendevreview | Merged openstack/nova master: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708 | |
| #openstack-nova - 2023-10-14 | |||
| 00:40:33 | opendevreview | Merged openstack/nova master: Warn if we find compute services in cell0 https://review.opendev.org/c/openstack/nova/+/897246 | |
| 03:20:24 | opendevreview | Takashi Natsume proposed openstack/nova master: Update contributor guide for 2024.1 Caracal https://review.opendev.org/c/openstack/nova/+/896305 | |