| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-10-12 | |||
| 18:11:08 | bauzas | +1 from me | |
| 19:20:55 | opendevreview | Dan Smith proposed openstack/nova master: Do not manage CPU0's state https://review.opendev.org/c/openstack/nova/+/898137 | |
| 19:21:08 | dansmith | bauzas: yw ^ | |
| 19:22:34 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP: add mtty support for vgpus https://review.opendev.org/c/openstack/nova/+/898100 | |
| 20:26:54 | sean-k-mooney | dansmith: before i finish for tonight do we want to merge the mdev plugin or wait for bauzas to modify nova to work with it first | |
| 20:27:34 | sean-k-mooney | im leanign towords merge since we can trivially revert it if we dont end up using it for any reason but i said i would ask first | |
| 20:27:44 | bauzas | I still need to test devstack witth precreated mdevs | |
| 20:28:14 | sean-k-mooney | ok we can wait then i was assuming your +2 ment you were ok to merge it but was not sure | |
| 20:28:50 | sean-k-mooney | im just clsoing broser tabs so said i would ask before i do | |
| 20:28:56 | sean-k-mooney | i can loop back to this on monday | |
| #openstack-nova - 2023-10-13 | |||
| 06:22:25 | gokhani | Good Morning Folks, I want to ask when we create snapshots with nova, can it also save memory state of instance? And an other one, when we use instance backed ceph volume, can it also save memory state when snapshotting? Thanks. | |
| 07:55:55 | tobias-urdin | gokhani: no to both questions, snapshotting memory is usually considered an enterprise feature that doesn't belong in cloud | |
| 08:19:32 | gokhani | tobias-urdin, you mean OPenstack snapshot is image/disk snapshot | |
| 08:20:29 | gokhani | I saw a spec but it is not implemented https://blueprints.launchpad.net/nova/+spec/instance-memory-snapshot | |
| 08:20:47 | gokhani | sorry it is not approved | |
| 08:24:36 | tobias-urdin | yes, it's disk | |
| 08:31:50 | sean-k-mooney[m] | we do not curently plan to add that feature | |
| 11:59:08 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Don not unnecessary convert images in finish_migration https://review.opendev.org/c/openstack/nova/+/897842 | |
| 11:59:34 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Do not unnecessary convert images in finish_migration https://review.opendev.org/c/openstack/nova/+/897842 | |
| 13:12:31 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Forbid use_cow_images together with flat images_type https://review.opendev.org/c/openstack/nova/+/898229 | |
| 13:35:06 | dansmith | sean-k-mooney: sorry I missed the notification for your question yesterday | |
| 13:35:23 | dansmith | sean-k-mooney: seems to me like it's working for you, me, bauzas and CI so it's worth merging IMHO | |
| 13:35:50 | dansmith | whether or not we can use those things or not is a different question and we can turn off the compilation if we want to with the flags | |
| 13:36:06 | bauzas | yeah the main problem is that I don't know whether we could use mtty | |
| 13:36:19 | bauzas | because of the libvirt non-support | |
| 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 | |