| *** ravlew is now known as Guest3203 | 04:18 | |
| 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. | 06:22 |
|---|---|---|
| tobias-urdin | gokhani: no to both questions, snapshotting memory is usually considered an enterprise feature that doesn't belong in cloud | 07:55 |
| gokhani | tobias-urdin, you mean OPenstack snapshot is image/disk snapshot | 08:19 |
| gokhani | I saw a spec but it is not implemented https://blueprints.launchpad.net/nova/+spec/instance-memory-snapshot | 08:20 |
| gokhani | sorry it is not approved | 08:20 |
| tobias-urdin | yes, it's disk | 08:24 |
| sean-k-mooney[m] | we do not curently plan to add that feature | 08:31 |
| 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 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Do not unnecessary convert images in finish_migration https://review.opendev.org/c/openstack/nova/+/897842 | 11:59 |
| 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:12 |
| *** haleyb|out is now known as haleyb | 13:33 | |
| dansmith | sean-k-mooney: sorry I missed the notification for your question yesterday | 13:35 |
| 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 |
| 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:35 |
| bauzas | yeah the main problem is that I don't know whether we could use mtty | 13:36 |
| bauzas | because of the libvirt non-support | 13:36 |
| bauzas | but let's merge it | 13:36 |
| dansmith | have we asked the libvirt guys to be sure? | 13:36 |
| bauzas | and we could just revert it if we find eventually that it's not able | 13:36 |
| bauzas | dansmith: not yet | 13:36 |
| bauzas | I had a lot of discussions with them | 13:36 |
| 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:37 |
| bauzas | but not for this :) | 13:37 |
| sean-k-mooney | bauzas: to me the libvirt gap is somethign we cna entrily work around in nova | 13:45 |
| 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 |
| sean-k-mooney | i have previously been tool we are not ment to add suprpot for emulated device just for testing | 13:46 |
| sean-k-mooney | but i would like to do that personally | 13:46 |
| 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 |
| bauzas | so if we need to go to the other way due to mtty, it would be bizarre | 13:47 |
| sean-k-mooney | bauzas: yes im aware we woudl need to call libvirt to create mdevs | 13:48 |
| bauzas | even if that's not for the same call | 13:48 |
| sean-k-mooney | but right now your calling sysfs to create tehm | 13:48 |
| bauzas | one is for getting mdev capable devices, the other one is for calling to create a mdev | 13:48 |
| sean-k-mooney | but libvirt to ask about capasity | 13:48 |
| sean-k-mooney | so its already split brained | 13:48 |
| bauzas | yes | 13:48 |
| bauzas | so, we would need to change both... | 13:48 |
| sean-k-mooney | so what i would do is if we provide a real pci adress in the config | 13:49 |
| sean-k-mooney | then we would just get the capstiy form libvirt | 13:49 |
| sean-k-mooney | if not we shoudl get it form sysfs since its a virtual device | 13:49 |
| sean-k-mooney | adn use libvirt to alwasy create mdevs instead of sysfs | 13:50 |
| 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 |
| 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 |
| sean-k-mooney | there are lots of way to make that cleaner | 13:51 |
| bauzas | sean-k-mooney: that's what I wrote in my mtty patch | 13:52 |
| sean-k-mooney | i.e. device_path /sys/devices/virtual/mtty/mtty or device_path=mtty/mtty | 13:53 |
| bauzas | if you pass "mtty" as a pci device, nova doesn't check the pci address | 13:53 |
| sean-k-mooney | sure but i dont thinkg we should pass mtty it shodl be mtty/mtty | 13:53 |
| bauzas | ok, so you would add a conditional, I see | 13:53 |
| sean-k-mooney | yes | 13:53 |
| sean-k-mooney | you basicaly alrady have | 13:53 |
| 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:53 |
| bauzas | sean-k-mooney : have you seen my uploaded mtty patch ? | 13:54 |
| 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 |
| sean-k-mooney | dansmith: i would like to supprot the virtual device by design | 13:54 |
| bauzas | the workaround is just to precreate the mdevs :) | 13:54 |
| sean-k-mooney | i.e. design for testablity and funcitonlity | 13:54 |
| sean-k-mooney | not just funcitonlity | 13:54 |
| sean-k-mooney | bauzas: that is fine too if it works | 13:55 |
| 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 |
| 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 |
| sean-k-mooney | since we cant recreate them as needed with the same values | 13:55 |
| sean-k-mooney | bauzas: so i guess for now to get soemthign workign we can precreate them in the ci job | 13:56 |
| bauzas | I'm just out of band for now | 13:57 |
| sean-k-mooney | but i think we can just make this work even without that with minimal extra complexity | 13:57 |
| bauzas | the customer issue went back | 13:57 |
| bauzas | and I also have a lot of back-and-forths internally with people afraid of the situation | 13:57 |
| bauzas | so I basically punted to continue working on mtty for today | 13:58 |
| bauzas | but last time I tried on my vm, mdev creation was working | 13:58 |
| bauzas | what I haven't tried yet was to download my patch and test it | 13:58 |
| bauzas | with precreated mdevs | 13:58 |
| dansmith | sean-k-mooney: ++ | 13:59 |
| dansmith | honestly I think creating on the fly makes plenty of sense, | 14:00 |
| dansmith | we just need a persistence mechanism, which is either libvirt or us | 14:00 |
| sean-k-mooney | we can perssitee them in the resouce table without any db modification | 14:01 |
| sean-k-mooney | if we want too | 14:01 |
| sean-k-mooney | or have libvirt do it | 14:01 |
| 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 |
| sean-k-mooney | both work | 14:01 |
| bauzas | the libvirt feature already exists | 14:01 |
| bauzas | https://libvirt.org/drvnodedev.html#example-of-a-mediated-device | 14:01 |
| sean-k-mooney | i know | 14:01 |
| bauzas | let's just use it | 14:02 |
| sean-k-mooney | which is why we want to use it. | 14:02 |
| sean-k-mooney | but im just saying this is a very solvable problem | 14:02 |
| bauzas | I'm not particulatly in favor of adding another datastructure in nova for something we can let the hypervisor handle | 14:02 |
| bauzas | and yet again a sync problem between the hypervisor and us | 14:03 |
| bauzas | (but that's MHO) | 14:03 |
| bauzas | again, priorities matter and that's on my scope | 14:03 |
| bauzas | I just have a limited 70hours bandwidth this week | 14:03 |
| dansmith | yep, agree we should not build data structures if we don't have to | 14:04 |
| sean-k-mooney | the reason we diding in the frist place was just because this was all ment to be tracked via placement | 14:04 |
| 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 |
| sean-k-mooney | but sure sound like we have a short term adn medium path forward | 14:05 |
| sean-k-mooney | shortterm just preacllocate the mdevs | 14:05 |
| sean-k-mooney | in the job | 14:05 |
| sean-k-mooney | medium term just make creation on the fly work with the fallback to reading /sys for aviablie_isntances | 14:06 |
| sean-k-mooney | in either case this is next week us problem i assume | 14:06 |
| bauzas | agreed with the plan | 14:06 |
| bauzas | I just need hands on deck | 14:07 |
| sean-k-mooney | we proceed with teh current devstack plugin and enhance it to do the other bits as we go | 14:07 |
| sean-k-mooney | *shall we | 14:07 |
| dansmith | bauzas: I know you | 14:07 |
| dansmith | are not suggesting that we're barking orders without helping right? | 14:07 |
| bauzas | no no | 14:08 |
| bauzas | this is just that this puzzle is horribly overcomplicated and I'm just a man | 14:08 |
| bauzas | and now the situation has been properly addressed and acked by above, I get many sollicitations :) | 14:09 |
| bauzas | (which is eventually good) | 14:09 |
| bauzas | so, yeah, taking one piece after the other | 14:09 |
| 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 |
| 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 |
| sean-k-mooney | im pulling th trigger on the devstack plugin patch lets impove it in followups | 14:13 |
| dansmith | sean-k-mooney: yep | 14:15 |
| opendevreview | Merged openstack/nova master: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708 | 16:25 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!