| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-10-12 | |||
| 17:24:40 | bauzas | so the DB still exists | |
| 17:24:44 | bauzas | DB record* | |
| 17:24:49 | bauzas | okay, will write the file | |
| 17:27:12 | dansmith | right which is exactly what that check is for :P | |
| 17:54:29 | bauzas | dansmith: actually, I have to doublecheck but since state_path is /opt/stack/data/nova, this probably goes away when you unstack | |
| 17:54:48 | dansmith | only when you clean I think | |
| 17:54:55 | dansmith | but you said it's not an AIO right? | |
| 17:55:07 | bauzas | yeah, just a single compute connecting to another instance | |
| 17:55:10 | dansmith | oh you mean nova's state path gets deleted | |
| 17:55:22 | bauzas | yeah, my theory is when unstacking | |
| 17:55:45 | dansmith | right, but that's the thing it's checking for.. that you basically rebuilt a node with the same name in place | |
| 17:56:00 | dansmith | if you don't want that, copy the uuid file to /etc/nova and it will re-use the same thing over and over | |
| 17:56:01 | bauzas | right, on purpose :) | |
| 17:56:13 | dansmith | (assuming you don't delete /etc/nova I guess unstack might) | |
| 17:56:33 | dansmith | maybe we need to let devstack force a uuid so we can keep it for subsequent stack runs | |
| 17:56:39 | dansmith | I always do AIO so I never hit that | |
| 17:56:56 | bauzas | anyway, not sure we need to change anything, but that's a bit complicating a story of a 2-node devstack install with the n-cpu failing once | |
| 17:57:48 | bauzas | maybe, for the moment, my brain is doing concurrency between a devstack install and a customer bug | |
| 17:58:08 | bauzas | so I don't have the energy to think about any potential solution | |
| 18:01:31 | dansmith | it's doing the thing it's supposed to which is catching that you've recreated a compute node with the same name without deleting it from the database | |
| 18:01:48 | dansmith | so either delete it from the DB, or slap the uuid file into place | |
| 18:02:06 | dansmith | I'll add something to devstack to basically disable that behavior by letting you force the uuid to be the same on each stack | |
| 18:10:13 | dansmith | bauzas: https://review.opendev.org/c/openstack/devstack/+/898134 | |
| 18:10:28 | dansmith | put a uuid in NOVA_CPU_UUID= in your localrc and you should be good | |
| 18:11:02 | bauzas | yup | |
| 18:11:06 | bauzas | excellent thing | |
| 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 | |