Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-01-19
16:23:43 womax` the work lead me to write code very similar on what is present in glance, and so I'm currently trying to propose moving the handling of tempURL in glance. But glance is not so keen on having features in glance that would only be used in ironic
16:24:39 womax` While working on temp URL we also saw a way to avoid glance being a bottleneck while downloading image, and so I wanted to ask opinions, on wether such a feature would exist, is it something that would be accepted to be used also in nova
16:25:22 womax` Idea would be in nova rather than downloading image directly from glance it would ask glance for a tempURL and then download the image from there (so directly from the storage backend)
16:28:45 fwiesel Funny thing, the vmware driver (in nova and cinder) could profit from it. We implemented in our fork that we generate a tempURL, because then the vcenter can download the image directly instead the having to pipe it through the nova-compute agent.
16:29:19 Uggla womax` I don't have strong opinion on that, because I don't know well that part. Clearly I would like to know what dansmith thinks about it.
16:29:25 nicolairuckel I have a topic for open discussion too (of course after that).
16:29:29 tkajinam sounds sensible to me
16:29:50 gibi what is the benefit of the direct download?
16:30:09 tkajinam gibi, IIUC it does not require proxy by glance
16:30:11 fwiesel gibi: Saving one hop
16:30:33 tkajinam in case glance uses swift backend currently when nova downloads an image from glance the data goes in swift -> glance -> nova
16:30:35 gibi OK so the use case here is better performance.
16:30:39 tkajinam but the proposal removes glance from the path
16:30:40 fwiesel Ah, and no token based authentication.
16:30:58 gibi any drawback?
16:31:03 womax` better performance for downloads but also avoiding glance being overloaded
16:31:25 gibi doea glance provide aome service we lose if we not go through it?
16:31:52 womax` gibi: from glance side, a token revocation would have take time to propagate, as tempURL have no to being revokated, but ttl is in order of minutes
16:32:05 womax` aome?
16:32:19 gibi sorry 'some'
16:33:24 womax` glance provide caching to avoid hitting too much the storage backend, temp URL would that, but it would be configurable and up to operators to see what is better for them
16:33:46 womax` other than that I don't think we would lose anything
16:34:12 womax` tempURL would bypass caching*
16:34:22 gibi OK. Based on these I feel like it make sense to draw up a spec to get quorum, but looks good to me so far
16:34:43 womax` spec in nova I assume?
16:34:45 fwiesel Well, another issue is reliability. tempUrls are shortlived by design, and if the tempURL expires during your download you cannot retry (by design). Openstack authentication is stronger, and has retry methods
16:35:17 gibi womax yepp spec in nova and in glance
16:35:36 womax` in glance it already drafted and they are currently waiting for nova opinions before going further
16:35:37 gibi i assume it impacts both
16:35:44 gibi cool
16:35:52 womax` I can also do it for nova to have more opinions
16:36:01 tkajinam fwiesel, yeah. we have service user token but it may not work for tempurl .
16:36:06 gibi yes please, and link the glance spec
16:36:27 gibi fwiesel: good point, lets include that to the spec to solve
16:36:31 womax` gibi: ok
16:37:06 tkajinam we probably need know better about the interaction between nova and glance so that we won't leak anything problematic
16:37:14 tkajinam especially in case a image is a shared one
16:37:45 tkajinam (We can discuss details in the spec)
16:37:50 gibi ++
16:38:15 fwiesel swift_store_multi_tenant=True is another edge case
16:38:39 womax` ok, i'll start drafting and come back when it is ready, to discuss more in details
16:38:59 tkajinam sounds nice :-)
16:40:51 Uggla Are we ok with that topic ? womax` ?
16:41:06 womax` Uggla: yes
16:41:30 Uggla ok so nicolairuckel, please go ahead with your topic
16:41:49 nicolairuckel I was wondering if it makes sense to move the discussion about how to deal with secure boot and resetting the NVRAM (https://review.opendev.org/c/openstack/nova/+/959682?tab=comments) from my patch to another place. This is relevant for cold migration which we excluded from my patch. The discussion is of course important for my (hopefully) next patch but I'm not sure where to put that/how to deal with that.
16:41:51 nicolairuckel Unless it is a blocker for my current patch of course. Last week it sounded like we need to discuss that beforehand but after reading the comments I'm not so sure anymore.
16:47:15 Uggla nicolairuckel my understanding, your patch just need a small addendum: prohibiting migration with os_secure_boot='optional' is an option. per haps its a suffience one for the short term
16:47:54 nicolairuckel I thought that's only an issue for cold migration.
16:48:27 tkajinam no it also affects bare hard reboot and hard reboot after live migration.
16:49:09 nicolairuckel Ah, somehow I missed that.
16:49:12 nicolairuckel Thank you.
16:49:17 nicolairuckel I'll work on that then.
16:49:18 tkajinam I think the point is that it's difficult to fix these all. I think we need an agreement about what we accept while fixing an annoying reset behavior
16:49:26 Uggla I don't think so, it seems something sean-k-mooney would like to have for this patch and then another one with a long term solution.
16:50:16 nicolairuckel But then it makes sense to have the discussion there and we don't really need to discuss that here.
16:50:27 sean-k-mooney oh o/
16:50:29 sean-k-mooney reading back
16:51:04 nicolairuckel i just missed that there's actually something else I need to do before the review can continue.
16:51:10 sean-k-mooney Uggla: honestly i think the os_secure_boot=optional stuff is out of scope
16:51:31 sean-k-mooney for the initall reboot patch
16:51:51 sean-k-mooney that was just ment to fix preserving the nvram file for hard reboot nothing more or less
16:52:32 Uggla ok
16:52:37 nicolairuckel Then my original point still stands that the discussion should be at another place, right? So we can merge the patch but don't lose the discussion in the process. I mean, it would still be there but kind of the wrong place.
16:52:52 nicolairuckel I'm just not sure how to proceed at the moment.
16:56:11 sean-k-mooney hard reboot in my opion shoudl nto change the secure boot state of the vm. that ideally woudl be fixed when the vm was first booted and stay the ame for its lifetime or only change on a resize or rebuild
16:56:34 sean-k-mooney im aware that not what happens today but i woudl prefer not to expand the nvram bug with fixing that
16:57:22 sean-k-mooney idealaly we woudl deal with os_secure_boot=optional as its own bug what ever way we decied to proceed with that
16:59:57 tkajinam sounds reasonable to me
17:00:03 Uggla nicolairuckel is that clarify your thoughts ?
17:01:03 nicolairuckel I think so. Then we create a new bug and leave the patch as is?
17:01:23 nicolairuckel Unless something comes up during the review of course.
17:01:36 Uggla yep that's my understanding.
17:01:39 sean-k-mooney that works for me but lets actully file the bug before proceedign with the patch
17:02:03 Uggla yep so we can relate to it
17:02:16 sean-k-mooney if we want to chat about that second bug we can do so briefly after teh meetign wraps
17:02:30 nicolairuckel sounds good to me. Who will file the bug?
17:02:51 Uggla nicolairuckel, if you are confortable to do it, that would be great.
17:04:48 Uggla Ok we are at the to of the hour. So I guess we can close that meeting.
17:05:08 Uggla Thanks for joining this meeting. Have a nice day/evening and see you next week.
17:05:21 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-19-16.02.log.html
17:05:21 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-19-16.02.txt
17:05:21 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-01-19-16.02.html
17:05:21 opendevmeet Meeting ended Mon Jan 19 17:05:21 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:05:21 Uggla #endmeeting
17:05:24 gibi thanks
17:06:01 Uggla no time for bug triage... I guess I need to find another way to address that topic.
17:06:12 tkajinam One thing I'd add about CI. Python 3.13 job was moved from Ubuntu Noble to Debian Trixie. it may cause some problems in python 3.13 jobs
17:06:31 tkajinam so far I'm aware that py313 job in python-novaclient is broken and https://review.opendev.org/c/openstack/python-novaclient/+/973846 fixes it
17:06:55 Uggla tkajinam, thanks for the info !
17:07:19 tkajinam (the migration was done only in master. py313 job in stable branches still runs in Noble)
17:07:37 tkajinam so it's better to keep eyes on py313 jobs for a while
17:07:56 tkajinam I mean openstack-tox-py313 and any jobs inheriting it
17:08:00 nicolairuckel I think it would make sense if tkajinam files the bug as he knows more about it but of course I can also write something and then update it with feedback from tkajinam and sean-k-mooney. I'm fine either way.
17:08:02 sean-k-mooney i think that woudl only cause issues if we had bindep problems like how we define pcre as a dep
17:08:23 tkajinam sean-k-mooney, yup
17:08:31 sean-k-mooney i could be wrong about that but it is good to keep an eye on the py313 job in any case
17:09:10 sean-k-mooney so for the secure boot optional case i have 2 tought on it
17:09:46 sean-k-mooney as i noted above i think the fact we dont fix the behavior on first boot is arguabel a but but that does not mean there is not merit in the current behavior
17:10:05 sean-k-mooney my concern with it ever changign after the workload is created is basiclly it can break the geust os if it does

Earlier   Later