Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-01-19
16:07:06 Uggla I haven't seen something special around the gates. Please tell me if I'm wrong.
16:07:41 Uggla #topic Release Planning
16:07:50 Uggla #link https://releases.openstack.org/gazpacho/schedule.html
16:07:56 Uggla #info Nova deadlines are set in the above schedule
16:08:03 Uggla #info 6 weeks before feature freeze
16:08:10 Uggla #info PTG etherpad for 2026.1 is available: https://etherpad.opendev.org/p/nova-2026.1-ptg
16:08:46 Uggla #topic Review priorities
16:08:51 Uggla #link https://etherpad.opendev.org/p/nova-2026.1-status
16:09:19 Uggla #topic OpenAPI
16:09:27 Uggla #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned
16:09:33 Uggla #info still 19 remaining atm.
16:09:38 Uggla #topic Stable Branches
16:09:54 elodilles thanks Uggla
16:10:04 elodilles actually, nothing to report
16:10:12 elodilles #info stable gates seem to be in good state
16:10:19 elodilles that's all from me for now
16:10:53 Uggla thx elodilles
16:10:56 elodilles np
16:11:14 Uggla #topic vmwareapi 3rd-party CI efforts Highlights
16:11:26 Uggla fwiesel, anything to report from your side ?
16:12:04 fwiesel No, nothing from my side.
16:12:09 fwiesel Uggla: Back to you
16:12:14 gibi fwiesel: one thing
16:12:46 gibi would it be possible to run the vmware job with nova-compute switched to threaded mode and using this patch? https://review.opendev.org/c/openstack/nova/+/973468
16:14:20 gibi https://docs.openstack.org/nova/latest/admin/concurrency.html#selecting-concurrency-mode-for-a-service this gives you the hint how to configure nova-compute to run in threaded mode
16:14:31 fwiesel Sure, should I activate the threaded mode by default? Or just one run?
16:14:58 gibi you need to pull in the nova-compute patches from that series
16:15:08 gibi and the oslo.vmware patches form the depends on
16:15:22 gibi and set the env variable OS_NOVA_DISABLE_EVENTLET_PATCHING=true
16:15:27 gibi for the nova-compute process
16:15:32 fwiesel So one manual run for now... I can do that.
16:16:01 gibi yepp just to see if the smokes comes out or nit
16:16:02 gibi not
16:16:03 gibi thank
16:16:04 gibi s
16:16:46 fwiesel You're welcome.
16:17:01 fwiesel Uggla: Now back to you, I presume.
16:17:18 Uggla thx
16:17:29 Uggla #topic Gibi's news about eventlet removal
16:17:41 gibi thanks
16:17:46 gibi no big news
16:18:03 gibi we made review progress in the nova-compute series
16:18:09 gibi that is all for now
16:18:23 gibi back to you
16:20:38 Uggla thx gibi.
16:20:39 bauzas we had back-to-back meetings but I saw your reply, I still wonder whether we're missing some libvirt event but fair
16:21:01 bauzas I'll accept your patch but I'll continue to monitor the jobs
16:21:34 Uggla #topic Open discussion
16:21:54 Uggla We have one topic from womax
16:21:59 Uggla (womax) Potential future use of tempURL in nova
16:22:06 womax` yes
16:22:09 Uggla womax` the floor is yours
16:22:53 womax` so for context, I recently worked in ironic to add support for multi store and s3 image stored. Ironic is using temp URL as way to download image on baremetal machine
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.

Earlier   Later