| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-23 | |||
| 10:06:45 | bauzas | shit | |
| 10:06:51 | gibi | I think we can ask the libvirt folks how do you feel about moving the libvirt memory snapshot, disk, and domain def to another compute and try to resume, if they say they support it then lets discuss further | |
| 10:07:24 | bauzas | sorry, I said "shit" because I was trying to understand exactly the diffs with suspend | |
| 10:08:19 | bauzas | gibi: again, I don't have the energy nor the will to push that more forward, I was just saying that the usecase may sound legit | |
| 10:08:51 | bauzas | let's not rathole on it, the answer is as of now "NOT SUPPORTED" | |
| 10:09:23 | gibi | as legit as requesting a brain transpart. legit but pointless if the tech is not there | |
| 10:10:18 | bauzas | the tech already allows us teleportation :) | |
| 10:10:41 | bauzas | but I hear ya | |
| 10:10:59 | bauzas | that would be an horrible spec to write and a terrible spec to review | |
| 10:11:28 | gibi | if teleportation you mean live-migration then yes libvirt has a bunch of tech implemented to support that, I'm not sure they have the tech to support brain transplant yet. | |
| 10:14:04 | gibi | btw that points to a direction actually. instead of shelving with a memory snapshot, do memory snapshot on the current hypervisor. The resume is supported there on the same hypevisor. I think the requesting people do not need the move aspect of shelve, they need the resumability only. So give them way to resume on same hypevisor | |
| 10:15:44 | gibi | wait we have that, they just get billed as they reseve the space to be able to resume | |
| 10:16:10 | gibi | so they don't want to get billed, but still want to make sure they can resume in place, that is contradicting | |
| 10:16:39 | gibi | or at least we are moving to interrutible instances territory to make space for resume | |
| 10:17:11 | gibi | (or what was the name of that feature that allows killing certian type of instances to make space for reservations) | |
| 10:18:43 | gibi | I guess I stop braindumping here as it is not exciting :) | |
| 11:06:56 | sean-k-mooney[m] | the reason shelve is more ligit then snapshot is it removes the snapshot once and create many copies uescase adn it also removes restore via rebuild | |
| 11:08:02 | sean-k-mooney[m] | so shelve/unshelve is much smaller in scope and has less sharp edges as a result | |
| 11:10:35 | sean-k-mooney[m] | gibi the reason sususped (which calls managed save) works today is we still have the domain so we can still restore it without worriing about the xml changing, managed save also does not allow pci passthough devices to be attached to the domain | |
| 11:12:11 | sean-k-mooney[m] | if i was to do shelve with memory my instict would say, save the xml and the memory as addtional images and reuse some of the live migraton logic to update the host side for it xml without modifying the guest visible side | |
| 11:12:51 | sean-k-mooney[m] | the same host does not really matter as long as the guest cant tell it moved | |
| 11:32:35 | gibi | sean-k-mooney[m]: I agree, move does not matter to the user if the instance works. I just pointing out that they also never requested the move, they only requests having a place to resume to but not getting billed for that place while suspended. | |
| 11:33:42 | gibi | btw having a vtpm live migration indeed seems even more important to get | |
| 11:35:06 | sean-k-mooney[m] | i mainly mentioned vtpm as another example of needing to store addtinoal data alongside the disk when shelving which we dont support today | |
| 11:35:44 | sean-k-mooney[m] | but also it a higher priority in my book but both are parralel efforts | |
| 11:37:14 | parasitid | hi gibi: i think i get you're point but there are still lots very obscure stuff to me because i'm definately not a specialist of this topic. When you say: "so they don't want to get billed, but still want to make sure they can resume in place, that is contradicting" why wouldn't it be possible to be resumed on a host supporting the same "flavor" ? why does it work in case of live migration and not unshelving ?. And yes i wouldn't | |
| 11:38:05 | parasitid | gibi: i just want to maximize the fact of being "resumable" but lowering the No Valid Host found error | |
| 11:40:03 | parasitid | btw, i didn't want to hijack your backlog by introducing this topic, i only wanted to know if there was a hidden feature/tips to achieve it. as it seems that its not currently supported im fine with it. don't worry. | |
| 11:41:34 | gibi | parasitid: no worries. I'm happy to discuss incoming request. I'm especially happy that it wasn't just a request but you are open to discuss it a bit deeper. | |
| 11:44:37 | gibi | parasitid: the devil is in the details of host supporting the same flavor. For nova supporting a flavor to boot a new VM on a host is differnt from supporting host as target for a live migration. And I assume it will be also different for supporting a host as a target for unshelve with memory. | |
| 11:45:08 | parasitid | gibi: yes. the starting point of my day was a test where i created and instance, open a vim in a tmux session, then suspended it, shelved it... Up to that point, as nova didn't complained about shelving a suspended instance, i secretly hoped that the resume would work :) | |
| 11:45:38 | parasitid | as i didn't find anything related to this in the docs, i jumped here to ask questions | |
| 11:46:06 | gibi | parasitid: what, nova allowed to shelve a suspended VM? That feels like an API validation bug :) (and also a way to raise false hope) | |
| 11:46:44 | gibi | parasitid: totally valid to jump and ask question. :) | |
| 11:47:59 | gibi | I think I'm debating mostly with bauzas about how acceptable this use case as is into our scope. | |
| 11:49:43 | gibi | and pointing out that even if we accept it there might me dependencies on libvirt / qemu we don't have right now to actually support it | |
| 11:50:56 | gibi | (and I think bauzas has a point about scope, the question boils down to how much we want to support enterprise virt vs. cloud) | |
| 11:52:17 | parasitid | by cloud you mean cloud native workloads ? | |
| 11:53:20 | parasitid | coz opening a vim in a tmux is not a cloud native workload :) | |
| 11:54:03 | parasitid | moreover.... i'm in the emacs team | |
| 12:01:40 | gibi | by cloud I mean VMs considered as cattle instead of pets | |
| 12:01:51 | gibi | you loose one, you create a new | |
| 12:01:57 | gibi | no feelings attached | |
| 12:06:01 | bauzas | sometimes this is a bit harder than that, like if you have some database service using memory :è) | |
| 12:07:51 | gibi | we have cluster aware DBs like galera. I think galera Active/Active/Active is possible. I assume that survives killing a VM | |
| 12:08:36 | gibi | if you only store your important data in memory then loosing that is not on nova | |
| 12:35:21 | bauzas | gibi: (sorry, was upgrading to F40), yeah I don't disagree with your point, I'm just saying that some cases are related to some memory usage | |
| 12:35:38 | bauzas | and just saying 'sorry, but cattle' doesn't help them | |
| 12:37:21 | gibi | I hope that it is OK to send the message that please also try to change the workload to be more cloudy. I hope this help them in the long run changing those workloads and enjoying the benefits. | |
| 12:38:07 | gibi | I do belive saying no sometimes actually helps :) | |
| 12:44:53 | opendevreview | Balazs Gibizer proposed openstack/nova master: Refactor obj_make_compatible to reduce complexity https://review.opendev.org/c/openstack/nova/+/928590 | |
| 12:44:54 | opendevreview | Balazs Gibizer proposed openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456 | |
| 12:44:54 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584 | |
| 12:44:55 | opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | |
| 12:55:58 | gibi | bauzas: can I drop the multipath_id and the novnc subpath topics from the nova meeting agenda? Or do we want to revisit them this week? I'm asking as I'm going to add https://blueprints.launchpad.net/nova/+spec/igb-vif-model to the agenda I noticed that those items might be stale | |
| 12:56:35 | bauzas | gibi: we discussed the multipath_id one | |
| 12:56:48 | bauzas | for the subpath, I think we also agreed the specless bp | |
| 12:56:51 | bauzas | so yeah | |
| 12:57:09 | gibi | OK, dropping them | |
| 12:57:26 | gibi | done | |
| 12:58:48 | bauzas | coo | |
| 12:58:51 | bauzas | cool even | |
| 13:05:52 | opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | |
| 13:12:20 | opendevreview | Brian Haley proposed openstack/nova stable/2023.2: libvirt: Cap with max_instances GPU types https://review.opendev.org/c/openstack/nova/+/916089 | |
| 13:52:50 | opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | |
| 16:15:23 | opendevreview | Doug Szumski proposed openstack/nova master: Revert "[libvirt] Live migration fails when config_drive_format=iso9660" https://review.opendev.org/c/openstack/nova/+/909122 | |
| #openstack-nova - 2024-09-24 | |||
| 08:32:05 | opendevreview | ribaudr proposed openstack/nova master: Amend ShareMappingStatus due to asynchronous call https://review.opendev.org/c/openstack/nova/+/908864 | |
| 08:32:05 | opendevreview | ribaudr proposed openstack/nova master: Amend DB model add a unique constraint. https://review.opendev.org/c/openstack/nova/+/912518 | |
| 08:32:06 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | |
| 08:32:06 | opendevreview | ribaudr proposed openstack/nova master: Use client token when talking to manila https://review.opendev.org/c/openstack/nova/+/925277 | |
| 08:32:07 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | |
| 08:32:07 | opendevreview | ribaudr proposed openstack/nova master: Mounting the shares as part of the initialization process https://review.opendev.org/c/openstack/nova/+/880075 | |
| 08:32:08 | opendevreview | ribaudr proposed openstack/nova master: Deletion of associated share mappings on instance deletion https://review.opendev.org/c/openstack/nova/+/881472 | |
| 08:32:09 | opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | |
| 08:32:10 | opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | |
| 08:32:11 | opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute manager part) https://review.opendev.org/c/openstack/nova/+/854824 | |
| 08:32:13 | opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to resume method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/860284 | |
| 08:32:14 | opendevreview | ribaudr proposed openstack/nova master: Support resuming an instance with shares (compute manager part) https://review.opendev.org/c/openstack/nova/+/860285 | |
| 08:32:15 | opendevreview | ribaudr proposed openstack/nova master: Add helper methods to rescue/unrescue shares https://review.opendev.org/c/openstack/nova/+/860286 | |
| 08:32:15 | opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares https://review.opendev.org/c/openstack/nova/+/860287 | |
| 08:32:16 | opendevreview | ribaudr proposed openstack/nova master: Allow to mount manila share using Cephfs protocol https://review.opendev.org/c/openstack/nova/+/883862 | |
| 08:32:17 | opendevreview | ribaudr proposed openstack/nova master: Check shares support (compute manager) https://review.opendev.org/c/openstack/nova/+/885751 | |
| 08:32:17 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (API) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 08:32:19 | opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/885753 | |
| 08:32:19 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | |
| 08:32:21 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | |
| 08:32:21 | opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | |
| 08:32:23 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282 | |
| 08:32:23 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach_error notification https://review.opendev.org/c/openstack/nova/+/860283 | |
| 08:32:25 | opendevreview | ribaudr proposed openstack/nova master: Reports instance events to the DB regarding attaching and detaching a share https://review.opendev.org/c/openstack/nova/+/927088 | |
| 08:32:25 | opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | |
| 08:32:27 | opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | |
| 08:32:27 | opendevreview | ribaudr proposed openstack/nova master: Docs about Manila shares API usage https://review.opendev.org/c/openstack/nova/+/871642 | |
| 10:52:40 | opendevreview | Takashi Kajinami proposed openstack/placement master: Remove Python 3.8 support https://review.opendev.org/c/openstack/placement/+/925648 | |
| 11:32:36 | zhhuabj | hi pas-ha[m] sean-k-mooney[m] we're really keen to see https://review.opendev.org/c/openstack/nova/+/909611 move forward and would like to know if there is anything we can do to help? it seems like it is now in final version and ready for review but has not had any in a while I understand it might have held up due to the raft of recent cves but hopefully that is now behind us and we are in a good position to move forward with this? | |
| 11:35:02 | sean-k-mooney[m] | that work stalled because we have a critical severity CVE related to image handleing in multiple openstack services | |
| 11:36:21 | sean-k-mooney[m] | as part of that 2 things were discovered, first iso work provided the iso is bootable when written to a block device, we can revert to using the cdrom device type to support iso that dont support that but thats why it was not noticed orginally | |
| 11:37:09 | sean-k-mooney[m] | the other thing that was discovered is the cve fix broke ISOs entirely :) that has now been fixed with the addtion of an iso format inspector | |
| 11:37:42 | sean-k-mooney[m] | we could revisit that not that the cve issues are resolved | |
| 11:37:47 | sean-k-mooney[m] | *now | |