| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-20 | |||
| 16:41:22 | sean-k-mooney | mnaser: i generally assume its an issue with the patch being backported until proven otherwise | |
| 16:41:22 | mnaser | (the same series i've been backporting for a few days now) | |
| 16:41:46 | mnaser | yeah.. i mean these patches are pretty trivial in that they just simply remove a flag from libvirt (and worked till 2023.1) | |
| 16:41:58 | mnaser | but yes i agree with you :) | |
| 16:42:02 | sean-k-mooney | so this looks liek a tempet config issue | |
| 16:42:10 | sean-k-mooney | it may be a tempet regression | |
| 16:42:16 | sean-k-mooney | Details: {'code': 409, 'message': 'Multiple possible networks found, use a Network ID to be more specific.'} | |
| 16:43:25 | mnaser | hmm | |
| 16:43:36 | mnaser | so something else needs to be backported? | |
| 16:44:15 | sean-k-mooney | i would assume so yes | |
| 16:44:32 | sean-k-mooney | im in another call in a primiarly listien role right now | |
| 16:44:38 | sean-k-mooney | so im slowlow lookign at this | |
| 16:44:38 | mnaser | ah no worries | |
| 16:50:32 | sean-k-mooney | looking at the master defintion im not seeing anythign related to the multiple netowrks | |
| 16:50:43 | sean-k-mooney | and im also not seeign any hcange to that test in tempest either | |
| 16:50:49 | sean-k-mooney | at least not recently | |
| 16:51:41 | sean-k-mooney | mnaser: my initial reaction is perhaps we shoudl exlude this one test for now until we can relove the test config issue | |
| 16:51:49 | sean-k-mooney | and then revert that as part of the fix | |
| 17:00:50 | opendevreview | Amit Uniyal proposed openstack/nova master: enforce remote console shutdown https://review.opendev.org/c/openstack/nova/+/901824 | |
| 17:01:57 | auniyal | sean-k-mooney, bauzas can you please review [enforce remote console shutdown] https://review.opendev.org/c/openstack/nova/+/901824 | |
| 17:32:09 | sean-k-mooney | auniyal: left comments inline | |
| 19:53:48 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Fix device type when booting from ISO image https://review.opendev.org/c/openstack/nova/+/909611 | |
| #openstack-nova - 2024-02-21 | |||
| 03:59:38 | opendevreview | Takashi Kajinami proposed openstack/nova master: SEV; Add TODO note about iommu setting done in recent QEMU https://review.opendev.org/c/openstack/nova/+/909635 | |
| 04:01:47 | opendevreview | Takashi Kajinami proposed openstack/nova master: SEV: Add TODO note about iommu setting done in recent QEMU https://review.opendev.org/c/openstack/nova/+/909635 | |
| 07:47:22 | adam-metal3 | Hi all! I am new to using openstack sdk and in general I am new in most openstack components, after reading the nova and openstacksdk docs I still have a question. I hope someone could give some direction. If I understand correctly multiple volumes could be attached to a VM and the VM can be booted from volume. | |
| 07:47:22 | adam-metal3 | Could there be a scenario where multiple bootable volume is attached to a VM and if yes then how could I tell via the openstacksdk that which volume was used for booting in this scenario? | |
| 07:52:22 | LarsErikP | jamespage: Hi! sorry if I'm getting annoying :P Any news on a SRU for zed containing nova 26.2.1? 👼 | |
| 08:35:25 | opendevreview | melanie witt proposed openstack/nova master: WIP Support encrypted backing files for qcow2 https://review.opendev.org/c/openstack/nova/+/907961 | |
| 08:35:26 | opendevreview | melanie witt proposed openstack/nova master: Support cross cell resize with ephemeral encryption for qcow2 https://review.opendev.org/c/openstack/nova/+/909595 | |
| 08:35:26 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for raw with LUKS https://review.opendev.org/c/openstack/nova/+/884313 | |
| 08:35:27 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912 | |
| 08:59:28 | opendevreview | Rajesh Tailor proposed openstack/nova master: Add support for showing requested az in output https://review.opendev.org/c/openstack/nova/+/904568 | |
| 09:29:22 | opendevreview | Takashi Kajinami proposed openstack/nova master: SEV: Add TODO note about iommu setting done in recent QEMU https://review.opendev.org/c/openstack/nova/+/909635 | |
| 10:24:06 | mnasiadka | Hello, I've raised https://bugs.launchpad.net/nova/+bug/2054437 - is that maybe by design or is that an actual bug? | |
| 11:18:39 | opendevreview | Dmitry Tantsur proposed openstack/nova master: ironic: clean up references to memory_mb/cpus/local_gb https://review.opendev.org/c/openstack/nova/+/878418 | |
| 13:36:21 | gibi | Uggla: sean-k-mooney: bauzas: discussing an edge case in the manilas series | |
| 13:36:57 | gibi | when the user detaches a share from a VM via the REST API and this is the last user of the share on the compute | |
| 13:37:03 | gibi | the share is unmounted | |
| 13:37:26 | gibi | lets assume that the unmounting fails on the compute | |
| 13:37:49 | gibi | should nova delete the share mapping and leak the mount | |
| 13:37:49 | sean-k-mooney | ... the detach instnace action should go to error | |
| 13:37:50 | gibi | OR | |
| 13:37:55 | sean-k-mooney | i think | |
| 13:38:03 | sean-k-mooney | an allow detach again via the api | |
| 13:38:04 | gibi | should nova put the mapping to ERROR and let the user retry | |
| 13:38:07 | sean-k-mooney | alternitivly we can have a perodic | |
| 13:38:27 | sean-k-mooney | i think letting the user retyr is good | |
| 13:38:36 | gibi | then we are on the same page | |
| 13:38:39 | sean-k-mooney | but nova could also retry if we wanted in a perodic | |
| 13:38:52 | gibi | periodic can be added separately yes | |
| 13:39:22 | Uggla | @sean-k-mooney, ok but it means the VM cannot be restarted until the error on the share is gone. | |
| 13:39:24 | sean-k-mooney | the periodic only comes to mind as the share being monted may mean that the data can be accessed on the host | |
| 13:39:43 | sean-k-mooney | and if there was a vm breakout it might expose mroe data to that mallious guest then woudl other wise be there | |
| 13:42:27 | Uggla | @sean-k-mooney, if I'm not wrong you wanted to be able to start the vm even if the share is in an error state for debugging. Am i wrong ? | |
| 13:44:18 | bauzas | sorry, I was preparing a meeting | |
| 13:46:02 | bauzas | gibi: I would agree with sean-k-mooney, the instance action should be an errort | |
| 13:46:16 | bauzas | so the user would need to detach the share again | |
| 13:46:39 | sean-k-mooney | i think we could allow starting the vm but not attch the errored share to it | |
| 13:47:16 | sean-k-mooney | or we could prevent that and require you to do the detach again before starting | |
| 13:47:28 | sean-k-mooney | im not sure what is the perfered approch here | |
| 13:48:09 | bauzas | sean-k-mooney: if we are not able to correctly umount the share by the compute, then we should continue to have a share mapping | |
| 13:48:48 | bauzas | I think Uggla doesn't support already mounted shares without having share mappings | |
| 13:48:52 | bauzas | Uggla: right? | |
| 13:48:57 | sean-k-mooney | thats fine | |
| 13:49:06 | sean-k-mooney | we can keep the vm in stopped with the share attach | |
| 13:49:13 | sean-k-mooney | and the instnace action in error | |
| 13:49:31 | sean-k-mooney | and then the user can either start the vm or try the detach again | |
| 13:49:32 | bauzas | yeah | |
| 13:49:35 | sean-k-mooney | depending on what they want | |
| 13:49:50 | bauzas | if they start the instance, they will have the share in it | |
| 13:49:58 | sean-k-mooney | if that is the approch we take then we dont need a perodic | |
| 13:50:05 | Uggla | I could add a detach force option, that will allow the instance to start ? (but leak the share, I could avoid db surgery) | |
| 13:50:06 | sean-k-mooney | yep | |
| 13:50:27 | sean-k-mooney | Uggla: please no :) we have scares form any time we add force | |
| 13:50:38 | Uggla | ok | |
| 13:50:39 | bauzas | Uggla: I can't remember, does your series support to look at shares that are altrady mounted ? | |
| 13:50:51 | sean-k-mooney | i think if we just start with the share mounted as if you never tired the detach then we are good | |
| 13:51:08 | sean-k-mooney | we just need to make sure that we dont update the vm unless the host unmount works | |
| 13:51:19 | Uggla | bauzas, yes you will be able to see the share in error state. | |
| 13:51:32 | sean-k-mooney | Uggla: the share does not need to be in error | |
| 13:51:42 | sean-k-mooney | the share can stay in attached/in-use | |
| 13:51:48 | sean-k-mooney | the instance action should be in error | |
| 13:52:00 | sean-k-mooney | oh actully | |
| 13:52:08 | sean-k-mooney | detach is not an instance ac tion n the normal case | |
| 13:52:17 | sean-k-mooney | do we have an instnace action event for detach | |
| 13:53:02 | sean-k-mooney | if we are going t oboot the vm with the share attached then the share attachemnt state should not be error | |
| 13:53:07 | Uggla | sean-k-mooney, yes there will have an instance action for detach. | |
| 13:53:11 | bauzas | Uggla: I need to look again at the spec then | |
| 13:53:16 | sean-k-mooney | ack then ya only that need to go to error | |
| 13:53:28 | sean-k-mooney | eveything else can keep its previous status | |
| 13:53:32 | bauzas | because I think users shouldn't know whether the share is already mounted or not | |
| 13:53:57 | sean-k-mooney | correct | |
| 13:53:59 | sean-k-mooney | we should not leak that | |
| 13:54:13 | sean-k-mooney | we should just report we failed to detach the share form the vm | |
| 13:54:33 | bauzas | tbc, I thought the detail was: | |
| 13:54:33 | sean-k-mooney | and unmounting it is part of that internally but not somethign we should tell the use via the api | |
| 13:54:45 | bauzas | as an user, I want to attach an instance to a share | |
| 13:54:58 | bauzas | it will create a share mapping | |
| 13:55:17 | bauzas | eventually, when I'm starting, then nova looks at the share | |
| 13:55:26 | bauzas | if the share is already mounted, cool | |