| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-18 | |||
| 10:53:34 | bauzas | tl;dr: if the API calls some old compute for getting the ConsoleAuthToken object, it will obtain a None value for the tls_port field | |
| 10:54:04 | bauzas | which basically works but returns 'null' (IIRC) as an API returned value | |
| 10:54:05 | mikal | I think that is ok. That would also happen if you had spice.require_secure set to false. | |
| 10:54:23 | mikal | i.e. a user of the API already has to handle that case. | |
| 10:54:30 | bauzas | mikal: cool, I wanted you to be aware of such value, feel free to leave a comment then to reply you're good with that | |
| 10:54:39 | mikal | Ok, will do. | |
| 11:09:16 | opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console object changes https://review.opendev.org/c/openstack/nova/+/926876 | |
| 11:09:17 | opendevreview | Michael Still proposed openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844 | |
| 11:09:17 | opendevreview | Michael Still proposed openstack/nova master: libvirt: direct SPICE console database changes https://review.opendev.org/c/openstack/nova/+/926877 | |
| 11:48:58 | sean-k-mooney | bauzas: can you review https://review.opendev.org/c/openstack/nova/+/940835 and https://review.opendev.org/c/openstack/nova/+/940873/6 in preperation for the spice series, that prepares the jobs to use spice, the devstack change to make multi node sspeice work proeprly is already merged so i coudl technially squash those but i think its simpler just ot merge them as is | |
| 11:49:38 | sean-k-mooney | im likely going to rename that job in a followup but i wont get to that for a while | |
| 11:50:19 | sean-k-mooney | im thinking nova-alt (i.e. for testing non default config that we do not plan to make the default, like nova-next but subtley differnt | |
| 11:50:21 | sean-k-mooney | ) | |
| 11:51:15 | sean-k-mooney | i plan to eventully renable the numa testing in that job and ill also try and add nova on nfs to it too | |
| 11:52:05 | sean-k-mooney | but i need to do some homework on exactly how to do that properly | |
| 12:33:01 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Reproduce bug/2097359 https://review.opendev.org/c/openstack/nova/+/942085 | |
| 12:33:02 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Update InstanceNUMACell version after data migration https://review.opendev.org/c/openstack/nova/+/942086 | |
| 12:33:03 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: Update InstanceNUMACell version in more cases https://review.opendev.org/c/openstack/nova/+/942087 | |
| 12:47:00 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Reproduce bug/2097359 https://review.opendev.org/c/openstack/nova/+/942088 | |
| 12:47:01 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Update InstanceNUMACell version after data migration https://review.opendev.org/c/openstack/nova/+/942089 | |
| 12:47:02 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.1: Update InstanceNUMACell version in more cases https://review.opendev.org/c/openstack/nova/+/942090 | |
| 12:49:59 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: repoduce post liberty pre vicoria instance numa db issue https://review.opendev.org/c/openstack/nova/+/942091 | |
| 12:50:00 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: allow upgrade of pre-victoria InstanceNUMACells https://review.opendev.org/c/openstack/nova/+/942092 | |
| 12:50:53 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: Reproduce bug/2097359 https://review.opendev.org/c/openstack/nova/+/942093 | |
| 12:50:54 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: Update InstanceNUMACell version after data migration https://review.opendev.org/c/openstack/nova/+/942094 | |
| 12:50:55 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2023.2: Update InstanceNUMACell version in more cases https://review.opendev.org/c/openstack/nova/+/942095 | |
| 13:23:47 | opendevreview | Amit Uniyal proposed openstack/nova master: WIP: remove swap.disk from disk.info https://review.opendev.org/c/openstack/nova/+/939643 | |
| 13:23:47 | opendevreview | Amit Uniyal proposed openstack/nova master: Reproducer for cold migration on shared storage https://review.opendev.org/c/openstack/nova/+/940304 | |
| 13:35:34 | opendevreview | Amit Uniyal proposed openstack/nova master: Reproducer for cold migration on shared storage https://review.opendev.org/c/openstack/nova/+/940304 | |
| 13:35:35 | opendevreview | Amit Uniyal proposed openstack/nova master: WIP: remove swap.disk from disk.info https://review.opendev.org/c/openstack/nova/+/939643 | |
| 14:35:39 | danfai | hi nova, I'm currently trying to understand live migration in a bit more detail, especially implications on the network model. My current use case is moving from Linuxbridge to OVN, and initial tests were promising to be able to do this with live migration in our context. When doing so nova seems to convert the vif correctly but in our case uses the bridge name from the source | |
| 14:35:41 | danfai | hypervisor, which then breaks. If I hardcode/override the vif_type/bridge name on the destination hypervisor, most things work (in our case). I see that part of it comes from neutron when asking about the vif type and it would get bridge. Another one I'm not sure where it comes from, but I guess from the rpc call from the source hypervisor. What I was wondering is, should | |
| 14:35:43 | danfai | bridge names not be independent of the source hypervisor and rather be calculated based on the destination hypervisors information? (our case libvirt/kvm, public network only, still yoga) | |
| 14:39:51 | danfai | (best part of it is, that if you migrate twice, it will use the correct bridge name as the vif_type would change) | |
| 15:18:23 | opendevreview | Sylvain Bauza proposed openstack/nova master: Support multiple allocations for vGPUs https://review.opendev.org/c/openstack/nova/+/845757 | |
| 15:18:24 | opendevreview | Sylvain Bauza proposed openstack/nova master: document how to ask for more a single vGPU https://review.opendev.org/c/openstack/nova/+/906151 | |
| 15:33:29 | bauzas | dansmith: sean-k-mooney: thanks for the reviews on the weigher, I got an interesting race condition that I need to fix fwiw https://review.opendev.org/c/openstack/nova/+/940642/9 | |
| 15:33:41 | dansmith | I saw | |
| 15:33:46 | bauzas | I'll probably try/catch the call | |
| 15:34:00 | bauzas | any other opinion ? | |
| 15:34:27 | sean-k-mooney | huh i see | |
| 15:34:34 | sean-k-mooney | that form looking upt the isntnaces on the host right | |
| 15:34:58 | sean-k-mooney | or rather there image properites | |
| 15:35:19 | sean-k-mooney | so ya wraping it in a try and ignoring it if the lookup fails makes sense | |
| 15:35:53 | sean-k-mooney | im not sure if you want to explcity handlel the detelete case or also skip if there is a general exception | |
| 15:36:08 | sean-k-mooney | like the cell db was not accsabel at the time | |
| 15:37:23 | sean-k-mooney | you shoudl handel nova.exception.InstanceNotFound for sure | |
| 15:48:37 | bauzas | sean-k-mooney: yeah, I'll go this way | |
| 15:48:49 | bauzas | because users can delete their instances anyway | |
| 15:48:59 | bauzas | even when scheduling | |
| 15:55:45 | sean-k-mooney | yep and in this case the instnace that could raise this migh belong to another tenant | |
| 16:01:06 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:01:06 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:01:06 | opendevmeet | Meeting started Tue Feb 18 16:01:06 2025 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:01:06 | bauzas | #startmeeting nova | |
| 16:01:12 | bauzas | howdy folks | |
| 16:01:17 | fwiesel | o/ | |
| 16:01:26 | r-taketn | o/ | |
| 16:01:46 | bauzas | wiki again is super slow | |
| 16:02:00 | bauzas | I updated it in advance but the update failed | |
| 16:02:28 | elodilles | o/ | |
| 16:02:57 | gibi | o/ | |
| 16:03:03 | bauzas | yeah it failed | |
| 16:03:19 | elodilles | did my update interfere with yours? :-o | |
| 16:03:23 | bauzas | okay, lemme bring you my notes directly | |
| 16:03:31 | bauzas | Error: 1205 Lock wait timeout exceeded; try restarting transaction (dd34c169f1ba97e28fc00622156bd8b2e9de60ef.rackspaceclouddb.com) | |
| 16:03:39 | bauzas | that's what I get | |
| 16:03:44 | elodilles | hmmm | |
| 16:03:55 | bauzas | #topic Bugs (stuck/critical) | |
| 16:04:02 | bauzas | #info No critical bug | |
| 16:04:09 | bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:04:16 | bauzas | any bugs to raise ? | |
| 16:04:49 | bauzas | looks not, moving on | |
| 16:05:24 | bauzas | agenda for today will be https://paste.opendev.org/show/bHNrlGFsGF7V7TpuLwGY/ | |
| 16:05:35 | bauzas | #topic Gate status | |
| 16:05:48 | bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | |
| 16:05:56 | bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | |
| 16:06:06 | bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status | |
| 16:06:31 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:07:03 | bauzas | #info Please try to provide meaningful comment when you recheck | |
| 16:07:10 | bauzas | that's it for gate | |
| 16:07:50 | bauzas | anything to talk about our gate ? | |
| 16:08:04 | bauzas | fwiw, I was more present upstream these days and found no real problem | |
| 16:08:38 | bauzas | moving on | |
| 16:08:42 | bauzas | #topic Release Planning | |
| 16:08:48 | bauzas | #link https://releases.openstack.org/epoxy/schedule.html | |
| 16:09:15 | bauzas | #info Nova deadlines are set in the above schedule | |
| 16:09:22 | bauzas | #info 1.5 week before Feature Freeze | |
| 16:09:29 | Uggla | o/ | |
| 16:09:30 | bauzas | the bell is ticking | |
| 16:09:38 | bauzas | #topic Review priorities | |
| 16:09:54 | bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | |
| 16:10:02 | bauzas | I eventually updated this etherpad \o/ | |
| 16:10:15 | bauzas | and I've started to do a round of reviews | |
| 16:11:51 | bauzas | anything we should discuss ? | |
| 16:12:09 | bauzas | if not, moving on in a sec | |
| 16:13:13 | bauzas | #topic PTG planning | |
| 16:13:19 | bauzas | as a reminder, | |
| 16:13:22 | bauzas | #info Next PTG will be held on Apr 7-11 | |
| 16:13:29 | bauzas | #link https://etherpad.opendev.org/p/nova-2025.2-ptg | |