Earlier  
Posted Nick Remark
#openstack-nova - 2026-05-11
16:45:55 dansmith I'm saying.. now that you know...
16:47:47 gibi I can review whatever patch remains :)
16:48:11 Uggla Sean’s comment is a bit ambiguous. I get the impression he prefers my version, but regardless, I’m going to try to move things forward.
16:48:57 dansmith so they are actually competing?
16:49:27 dansmith I mean if that's the case, then fine, but let's figure out which one we want and close the other.. having two proposed without active management towards a decision is just asking for them to be ignored, IMHO
16:50:32 Uggla yes sure.
16:51:05 Uggla #topic Bug scrubbing
16:51:12 Uggla #info up to 193 (+2)
16:51:19 Uggla #link https://etherpad.opendev.org/p/nova-bug-triage-roster
16:51:24 Uggla #link https://truc.uggla.fr/ to follow the trend.
16:51:29 Uggla #info New bugs assigned.
16:51:35 Uggla Next meeting (this week): [public] Upstream bug triage. Wednesday, May 13 · 15:30 – 16:00 UTC. Video call link: meet.google.com/qdd-fwzs-tje
16:52:11 gibi I'm affraid I have to skip it again. I promise I'm not intentionally avoiding it
16:53:05 sean-k-mooney Uggla: if its the one im thinking of you had better testing but i prefer there version
16:53:30 sean-k-mooney Uggla: in either case it woudl be nice to converge them
16:54:24 Uggla sean-k-mooney, ok thanks for the clarification.
16:54:28 Uggla Are you abandoning me?
16:54:34 Uggla gibi ^
16:54:36 Uggla ;)
16:55:05 dansmith sean-k-mooney: agree I prefer the original patch (in terms of the runtime code)
16:55:14 gibi Uggla: It is complicated ;)
16:55:31 sean-k-mooney dansmith: more reuse and uses len()
16:55:41 dansmith also, the original patch has unanswered questions/comments from gibi AFAICT
16:55:43 dansmith sean-k-mooney: exactly
16:56:11 sean-k-mooney its been a while since i looked at either so i have not seen them
16:56:18 dansmith basically precisely what I said in a review a few minutes ago
16:56:24 sean-k-mooney ack
16:57:10 sean-k-mooney Uggla: maybe you coudl take over both patchs and adress gibi's comments
16:57:31 sean-k-mooney or even just add your extra tests into ther patch for them
16:58:03 Uggla yes I thought about the latest option.
16:58:20 Uggla which looks simpler.
16:58:48 Uggla #topic Open discussion
16:59:19 Uggla nothing on the agenda. So I think we can close. Unless someone has a 2mn things to say
17:00:15 Uggla TBH I wanted to discuss a bug, but I'll do it outside of the meeting.
17:00:33 Uggla So I think we are done for today
17:00:59 Uggla Time to close, thanks for joining this meeting. Have a nice day/evening.
17:01:07 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-05-11-16.00.log.html
17:01:07 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-05-11-16.00.txt
17:01:07 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-05-11-16.00.html
17:01:07 opendevmeet Meeting ended Mon May 11 17:01:07 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:01:07 Uggla #endmeeting
17:01:16 gibi thanks Uggla
17:01:57 dansmith Uggla: just some feedback from me.. it feels like the pace of the meetings has really slowed to a crawl lately and it's feeling like there's a lot of dead space.. I wonder if we could pick up the pace a bit and try to make it a quicker in-and-out sort of thing?
17:02:12 dansmith maybe it's just me, in which case ignore me, but.. might be worth considering
17:03:04 sean-k-mooney the last few meeting i have either been double booked or not able to focus much on ti so cant commet if tis just dan but ya it proably coudl be a littel snappier
17:03:44 dansmith right, it's easy to get distracted because the pace is so slow and I tend to do other things to try to fill the minutes
17:06:44 Uggla Oh, I didn't realize! I'll definitely try to make it snappier next time.
17:11:10 dansmith thanks :)
17:11:31 opendevreview Dan Smith proposed openstack/nova stable/2026.1: Fix resize to unpermitted flavors https://review.opendev.org/c/openstack/nova/+/988148
17:21:19 opendevreview Dan Smith proposed openstack/nova stable/2025.2: Fix resize to unpermitted flavors https://review.opendev.org/c/openstack/nova/+/988153
17:21:20 womax of how much I should go in details
17:21:20 womax sean-k-mooney: hi I updated the spec for tempurl usage (https://review.opendev.org/c/openstack/nova-specs/+/975883), last time you said it was a bit lacking in details, and apart for explicity adding the use of download_handlers, I did not feel I have added much. If you had some part in mind that were lacking details, and if it was more an overall impressions I'm curious if you could point to me to a spec I could refer to have an idea
17:21:48 opendevreview Dan Smith proposed openstack/nova stable/2025.1: Fix resize to unpermitted flavors https://review.opendev.org/c/openstack/nova/+/988154
17:22:17 dansmith womax: I think I'm a but unsure about this one after PTG
17:22:33 dansmith womax: it sounded to me like you were saying that ironic and glance wanted/needed this and nova could benefit,
17:22:46 dansmith but then talking to the glance people it sounded like that wasn't really the case
17:23:01 dansmith so I'm left wondering.. is this something ironic wants nova to do specifically?
17:27:08 womax dansmith: ok I wasn't trying to say that, my point was I (and overall OVH) would like to have a tempurl management feature in glance. glance people were not really interested, especially if it will not be used anywhere. So my point was to see if such a feature would exist in glance, could a use be implemented in nova. And if so I would go back to glance to discuss more about if is something that can go further
17:28:01 womax And for the ironic, it was where I did find tempurl at first that was done only for swift, but I don't think it should interact much with nova
17:28:16 dansmith okay, I think that's what I took from it after getting the full picture.. that nova's implementation here would just help to justify the glance feature
17:29:18 womax yes that's it
17:29:23 dansmith gotcha
17:37:03 womax and linked to that, I tried to experiement a bit with the download handler code path, to see what the implmemention could look like. And I was under the impression that it cannot works if glance show_multiple_locations config is false (which is the default (https://docs.openstack.org/glance/latest/configuration/glance_api.html#DEFAULT.show_multiple_locations), as nova never seems to call the dedicated route to get locations
17:37:04 womax (/v2/images/{image_id}/locations), (https://opendev.org/openstack/nova/src/branch/master/nova/image/glance.py#L253). I don't know if it normal/bug, or if I missed something else, but I could never make it even try to see if download_handlers existed without a bit of modification in the nova code
#openstack-nova - 2026-05-12
07:42:34 gibi Hi folks it seems nova-alt-configuration job is started to fail since yesterday
07:42:38 gibi https://zuul.opendev.org/t/openstack/builds?job_name=nova-alt-configurations&branch=master&skip=0
07:43:10 gibi May 11 20:41:52.111833 npfa8fa206b4014 nova-compute[32688]: ERROR nova.compute.manager [instance: 0de2d300-db70-420c-a502-c6015ad70e94] libvirt.libvirtError: unsupported configuration: spice graphics are not supported with this QEMU
07:43:14 gibi May 11 20:41:52.111833 npfa8fa206b4014 nova-compute[32688]: ERROR nova.compute.manager [instance: 0de2d300-db70-420c-a502-c6015ad70e94] libvirt.libvirtError: unsupported configuration: spice graphics are not supported with this QEMU
07:43:19 gibi https://zuul.opendev.org/t/openstack/build/7f08461295e24d3b8f1673f29dd9f711/log/compute1/logs/screen-n-cpu.txt?severity=4
07:45:43 gibi this can be relevant https://review.opendev.org/c/openstack/devstack/+/968354
07:49:57 frickler gibi: iiuc you need to install an extra pkg for that, see also https://review.opendev.org/c/openstack/kolla/+/972441/4/docker/nova/nova-libvirt/Dockerfile.j2
07:52:26 gibi frickler: thanks for the pointer
07:56:03 gibi I will push a fix in devstack then
07:57:42 frickler looks like the failure was already present in the testing patch, but wasn't noticed https://review.opendev.org/c/openstack/nova/+/968892
08:06:15 gibi indeed
08:06:39 gibi it is partially me who approved the devstack patch yesterday who missed that failure.
08:07:09 gibi I pushed https://review.opendev.org/c/openstack/devstack/+/988214 to fix it
08:09:06 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: test nova-alt-configuration https://review.opendev.org/c/openstack/nova/+/988215
08:09:15 gibi testing it in ^^
08:15:43 mikal gibi: yeah, the Debian Trixie qemu requires an additional package for SPICE. Same deal with Ubuntu FWIW.
08:34:24 gibi mikal: TIL :)
08:34:32 gibi elodilles: for your eyes https://review.opendev.org/q/I469688be203c319dd048d6a99057b8d98369de0e
08:42:20 elodilles gibi: ACK, i'll keep an eye on them
09:16:50 sean-k-mooney gibi: am i belive speice is an optional package on debian 13 and 12 + backport likely has the same pattern
09:17:08 sean-k-mooney ah yep
09:17:25 sean-k-mooney gibi: mikal so i have been meaning to move that job to debian 13 for a while now
09:21:22 mikal sean-k-mooney: yeah fair enough. I am working on a job for Kolla-Ansible at the moment, but that's likely heavier weight than what you'd want in Nova.
09:22:05 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/966479
09:22:44 sean-k-mooney was the change i worked on 6 months ago i just didnt get around to the followup for addign the spice module expelcitly
09:22:52 sean-k-mooney at least not that isee upstream
09:23:45 mikal I'd like to do stronger assertions that SPICE is actually working, not just getting the server "banner" back, but that's a thing I've wanted for a while and am only just getting to now.
09:24:08 sean-k-mooney mikal: i mena we could do that
09:24:28 sean-k-mooney it really just depends on what that looks liek and how much time it addes to the job
09:25:05 mikal Well, I have most of a headless SPICE client working now. I want to have a bit more a test workload which enumerates a bit of the protocol as well though. I don't think it would make the job much slower, apart from needing to download (or cache) the client and target instance image.
09:25:14 mikal But forward looking statements etc etc.
09:26:12 sean-k-mooney well if you end up packagign this as a tempest/devstack plugin that we coudl teadilly enable we coudl consider addign it
09:27:04 sean-k-mooney s/teadilly/readally or eaisilly/?
09:27:11 sean-k-mooney oen of those words
09:29:07 mikal Just as soon as I learn what a tempest plugin (or Claude tells me), I will consider that thing.
09:29:28 sean-k-mooney its just a way of packaging tempst test in a seperate repo

Earlier   Later