| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-20 | |||
| 08:15:50 | opendevreview | OpenStack Release Bot proposed openstack/nova stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/nova/+/930006 | |
| 08:15:54 | opendevreview | OpenStack Release Bot proposed openstack/nova master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/nova/+/930007 | |
| 08:26:18 | gibi | \o/ | |
| 08:28:46 | opendevreview | Amit Uniyal proposed openstack/nova master: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/929858 | |
| 09:45:55 | opendevreview | Merged openstack/nova stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/nova/+/930005 | |
| 09:46:01 | opendevreview | Merged openstack/nova stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/nova/+/930006 | |
| 09:46:07 | opendevreview | Merged openstack/nova master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/nova/+/930007 | |
| 10:30:53 | stephenfin | gibi: bauzas: sean-k-mooney[m]: Now that you have rc1 out, could I ask you to test whether OSC 7.1.2 resolves the CI issues so we can uncap it? | |
| 10:31:22 | sean-k-mooney | sure ill repoint my dnm one sec | |
| 10:31:33 | stephenfin | We should obviously wait until Monday to do the uncap so we can take advantage of the weekend to run whatever tests we want to run | |
| 10:31:36 | stephenfin | sean-k-mooney: ty | |
| 10:32:03 | sean-k-mooney | i actully have a devstack again so i can maybe pull it in and try a few things if there is anything sepcific you want tested | |
| 10:32:13 | sean-k-mooney | our jobs dont relaly use osc much | |
| 10:32:54 | sean-k-mooney | stephenfin: do you have the link to the requirements bump patch | |
| 10:33:18 | gibi | stephenfin: sure, lets resulve the pinning situation | |
| 10:33:23 | stephenfin | https://review.opendev.org/c/openstack/requirements/+/929938 | |
| 10:33:25 | sean-k-mooney | ah https://review.opendev.org/c/openstack/requirements/+/929938 | |
| 10:33:39 | stephenfin | the -1 is because of the pinning, naturally | |
| 10:33:45 | opendevreview | sean mooney proposed openstack/nova master: [DNM] testing pinning osc to 7.1.2 https://review.opendev.org/c/openstack/nova/+/929758 | |
| 10:34:03 | stephenfin | hmm, I wonder if we need to edit that to remove the pin | |
| 10:35:25 | sean-k-mooney | for testing no but to pass the ci yes | |
| 10:38:15 | sean-k-mooney | hecking /home/zuul/src/opendev.org/openstack/requirements/global-requirements.txt | |
| 10:38:17 | sean-k-mooney | Constraint 7.1.2 for python-openstackclient does not match requirement ['<7.0.0'] | |
| 10:38:49 | sean-k-mooney | on the other hand since that cant merge currently until you fix that it wont be merged by mistake :) | |
| 10:40:13 | sean-k-mooney | oh i actully cant test that because it detected it cant merge | |
| 10:41:10 | sean-k-mooney | ok cool rechecked | |
| 10:42:14 | sean-k-mooney | https://zuul.openstack.org/status?change=929758 is running so we will see if it impacts our jobs in about 2 hours | |
| 13:15:15 | bauzas | stephenfin: sean-k-mooney : sorry folks, my internet connection is horrible today, so I'm a bit on and off | |
| 13:15:48 | bauzas | what we could do is to test the OSC7.1.2 release without the CI | |
| 13:15:56 | bauzas | I think gibi did it | |
| 13:16:01 | bauzas | with my change | |
| 13:16:12 | sean-k-mooney | i also tested it with ci https://review.opendev.org/c/openstack/nova/+/929758 | |
| 13:16:24 | bauzas | cool | |
| 13:16:26 | sean-k-mooney | it works for the limited usage we have in our gate | |
| 13:16:45 | stephenfin | Yeah, I think we're good to go now so | |
| 13:16:50 | stephenfin | Will pick that up Monday | |
| 13:16:54 | sean-k-mooney | bauzas: i have a seperate dnm that alows us to test any change to osc before its merged | |
| 13:17:05 | bauzas | ++ | |
| 13:17:31 | bauzas | tbh, now we have RC1, I'm fine with using OSC7.x for 2025.1 | |
| 13:17:32 | sean-k-mooney | if we jsut add a depends on agaisnt osc to https://review.opendev.org/c/openstack/nova/+/929757 | |
| 13:17:47 | sean-k-mooney | we can test any patch | |
| 13:18:39 | sean-k-mooney | the requiremetns repo is alwasy used for source in the devstack jobs | |
| 13:19:14 | sean-k-mooney | meaning we can always tests any requirement bump after a release is done and beofre uc is updated | |
| 13:19:56 | bauzas | good with me | |
| 13:41:20 | opendevreview | Matthew Heler proposed openstack/nova stable/2023.2: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929968 | |
| 13:44:55 | opendevreview | Matthew Heler proposed openstack/nova stable/2023.2: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929968 | |
| 14:54:30 | opendevreview | Matthew Heler proposed openstack/nova stable/2023.2: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929968 | |
| 14:55:04 | opendevreview | Matthew Heler proposed openstack/nova stable/2023.2: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929968 | |
| 14:57:45 | opendevreview | Matthew Heler proposed openstack/nova stable/2023.1: Fix regression with live migration on shared storage https://review.opendev.org/c/openstack/nova/+/929969 | |
| 15:33:57 | haleyb | bauzas: do you mind if i push an update for https://review.opendev.org/c/openstack/nova/+/916089 to fix the merge conflicts? have seen this downstream now | |
| 17:25:17 | opendevreview | Takashi Natsume proposed openstack/nova master: Update contributor guide for 2025.1 Epoxy https://review.opendev.org/c/openstack/nova/+/929918 | |
| 17:25:20 | opendevreview | Amit Uniyal proposed openstack/nova master: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/929858 | |
| 17:27:13 | opendevreview | Amit Uniyal proposed openstack/nova master: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/929858 | |
| #openstack-nova - 2024-09-22 | |||
| 03:08:27 | opendevreview | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/c/openstack/nova/+/929719 | |
| 08:35:16 | opendevreview | Takashi Natsume proposed openstack/python-novaclient master: Remove WebOb < 1.6.0 Code https://review.opendev.org/c/openstack/python-novaclient/+/930165 | |
| #openstack-nova - 2024-09-23 | |||
| 08:04:17 | bauzas | haleyb: sure, shoot | |
| 09:05:23 | parasitid | hi all, i have a question regarding the shelving process. would it be possible to "suspend" then shelve an instance, and unshelve + resume so that i can resume my instance on another host without restarting the OS ? Currently it seems that unshelving an instance reboots the VM and that its state file is lost during the shelving process. Am i correct ? thanks a lot | |
| 09:17:44 | pas-ha[m] | parasitid: I don't think 'shelving' saves a memory dump.. it only saves a disk state. Shelving is literally 'shutdown and create an image', and shelve-offload is '..and de-allocate resources' (removes local disk files, removes allocations in placement but keeps the instance in the DB). | |
| 09:18:18 | pas-ha[m] | And 'unshelving' just means 'rebuild the instance from the image we saved in the shelve command' | |
| 09:22:20 | parasitid | pas-ha[m]: ok thanks that's what i thought. I hoped that the state machine would differentiate an instance active state > shelved state and "instance suspended state" > shelved state. it could be nice to offload the instance state file if suspended so that unshelving an instance could restore its states | |
| 09:22:36 | bauzas | parasitid: you need to live-migrate your instance if you want to keep the instance alive | |
| 09:22:59 | bauzas | shelve means "stop my instance and put it in the shelve" :) | |
| 09:24:15 | parasitid | bauzas: well my usecase is : start a instance, use it. shelve it so i'm potentially not billed by the cloud provider. unshelve it and recover previous working environment | |
| 09:24:52 | pas-ha[m] | I don't think nova has anything similar to libvirt/virt-manager 'save VM' which is kind of like hibernate - dump a memory to a file, and resume from that (and disk) later. | |
| 09:25:16 | bauzas | snapshot it | |
| 09:25:23 | pas-ha[m] | that's what would be required for your use case as you want to save the memory as well | |
| 09:25:52 | bauzas | you could also suspend the VM | |
| 09:26:12 | bauzas | but your cloud provider will probably continue to bill you | |
| 09:26:45 | parasitid | bauzas: yes, but suspending a VM keeps the resources allocated, so you're often billed by the cloud provider. whereas shelving it frees the resources | |
| 09:27:01 | bauzas | sure, but that's why you need to stop the instance, right? | |
| 09:27:54 | bauzas | when you shelve, IIUC, you'll get a memory snapshot | |
| 09:28:36 | bauzas | sorry, a disk snapshot I mean | |
| 09:28:45 | bauzas | but the memory will be lost | |
| 09:30:08 | parasitid | bauzas: ok. couldn't the shelve process consider the VM state and also backup/restore the memory state file if ever the instance was in suspended state ? | |
| 09:32:02 | bauzas | I see your usecase tbc | |
| 09:32:42 | bauzas | but the problem here is that for the moment, AFAIK nova isn't able to save the memory | |
| 09:32:49 | parasitid | bauzas: usecase would be VDI/remote desktop | |
| 09:32:54 | bauzas | yup, I got it | |
| 09:33:18 | bauzas | that's in general *why* people want to save the memory :D | |
| 09:34:49 | bauzas | honestly, I don't know what to tell you, except that it would need a new feature | |
| 09:34:49 | parasitid | bauzas: are you sure ? i made a test this morning. when i suspend an instance and resume it, i can ssh back into my instance and tmux attach to my session and recover the vim buffer right where is was before suspending | |
| 09:35:20 | bauzas | suspend works indeed with the memory, but we don't snapshot it | |
| 09:35:31 | bauzas | that's why I said above "snapshot it" | |
| 09:35:39 | parasitid | bauzas: ok thanks. i understand perfectly. i jumped here just in case there would be a secret tip to achieve this :) | |
| 09:35:47 | bauzas | but your usecase is different : you want to /persist/ it | |
| 09:36:07 | bauzas | tbh, VMware supports that AFAIKK | |
| 09:36:18 | bauzas | (memory snapshot) | |
| 09:36:34 | bauzas | but as I said here, we need some new feature and some new API support for it | |
| 09:36:36 | bauzas | sean-k-mooney: ^ | |
| 09:38:30 | bauzas | (that and live-resize are possibly the most needed features we'd like to have for VMware migration :) ) | |
| 09:39:40 | bauzas | sean-k-mooney: I wonder, could we help parasitid with file-backed memory? | |
| 09:41:08 | bauzas | (oh I forgot, sean is on PTO this week) | |
| 09:43:31 | sean-k-mooney[m] | we have talked about this in the past, libvirt can do memory snapshots but we can because we do not guarantee a stable hardware interface | |
| 09:44:36 | sean-k-mooney[m] | when you unshleve you might shelve to a differnt host with differnent cpu, the pci device order in the guest may or may not be the same and if you have any sriov device there memory would not be captured | |
| 09:46:32 | sean-k-mooney[m] | we may be able to make it work in some cases but we would have to save and store the memory as an addtional image and also might need to recored other info about the guest like the pci device ids instead of allowing libvirt to choose them | |
| 09:47:08 | sean-k-mooney[m] | but no file backed memory will not help here. libivrt has a call to take a snapshot and include the guest memory | |
| 09:47:17 | sean-k-mooney[m] | so its not that we cant do that | |
| 09:48:55 | gibi | yeah shelve with memory would be like: hibernate your guest, write the image to disk, bring the image to another hardwared, and try to resume from hibernation. As far as I know if I change my hardware while my machine is hibernated and I try to resume I very well be in kernel panic territory | |
| 09:49:09 | sean-k-mooney[m] | for instances with no passthough devices like neurton sriov ports, or vgpus that use cpu_mode=custom and a pinned cpu model it proably would work | |
| 09:50:16 | gibi | wondering what restiction libvirt puts on resuming from memory snapshot while the hypervisor is reconfigured inbetween | |