Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-08-19
16:23:53 gibi so feel free to skip it or do it without me
16:24:22 gibi I know Kamil updated the nova-conductor series after my feedback but I had no time to go back to it yet
16:24:30 gibi that is all from me
16:24:33 gibi back to you Uggla
16:24:45 Uggla Cool thanks Gibi !
16:25:22 Uggla #topic Open discussion
16:26:07 Uggla #info FYI, I'm a volunteer for the next cycle. 957240: Adding René Ribaud candidacy for Nova 2026.1 PTL | https://review.opendev.org/c/openstack/election/+/957240
16:26:38 gibi thanks Uggla
16:26:43 tkajinam Thanks for stepping up, Uggla++ :-)
16:26:44 Uggla That's all I have
16:27:08 Uggla Does someone have a topic ?
16:28:26 tkajinam no additional topic from me
16:29:39 Uggla ok moving on.
16:29:47 Uggla #topic Bug scrubbing
16:30:43 Uggla #info down to 172, I manage to answer reporters about some invalid or incomplete ones.
16:32:03 Uggla If you don't mind I will skip the scrubbing today, because we are only few today, and my eyes hurt.
16:32:19 sean-k-mooney o/ sorry was distraced down stream
16:33:10 Uggla Hi sean-k-mooney, any last topic you want to bring ? Otherwise I think I will close for todaY.
16:34:08 sean-k-mooney no didnt really have anything
16:34:17 sean-k-mooney was just reading back
16:34:50 sean-k-mooney the main thing is obviously the bug we are currently backporting but htere is nothing actionabl to do on that
16:35:10 Uggla The security one ?
16:35:23 sean-k-mooney ya we are just making our way through the stable branches
16:35:38 sean-k-mooney thanks elodilles for taking a look by the way
16:35:54 elodilles sean-k-mooney: no problem, thanks for fixing it o:)
16:36:18 sean-k-mooney elodilles: on the watcher side we will probly do release fot his and the other pending patches at the end of the week or next week
16:36:24 sean-k-mooney ill prepare patches for those
16:36:43 elodilles sean-k-mooney: ACK, thanks for the notice, i'll try to take an eye on it
16:37:04 elodilles 1st release patch for nova is up btw: https://review.opendev.org/c/openstack/releases/+/957951
16:37:14 elodilles Uggla: ^^^ fyi o:)
16:37:17 sean-k-mooney Uggla: so ya thats all i had so we can wrap if there are no other topics
16:38:13 elodilles (i'll update 2024.2 dalmatian release patch when the patch gets merged and prepare 2024.1 caracal one too)
16:39:23 Uggla elodilles cool, I'll look at it tomorrow.
16:39:31 opendevreview Merged openstack/nova master: only show standard image properties in server show. https://review.opendev.org/c/openstack/nova/+/942413
16:39:31 elodilles thanks in advance o/
16:40:03 Uggla So I'm gonna close, thanks all.
16:40:08 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-19-16.00.log.html
16:40:08 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-19-16.00.txt
16:40:08 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-08-19-16.00.html
16:40:08 opendevmeet Meeting ended Tue Aug 19 16:40:08 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:40:08 Uggla #endmeeting
16:40:11 elodilles thanks Uggla o/
16:40:14 tkajinam thanks
16:44:26 opendevreview sean mooney proposed openstack/nova stable/2025.1: only show standard image properties in server show. https://review.opendev.org/c/openstack/nova/+/957958
16:44:52 sean-k-mooney ... that has conflicts let me do that form the cli instead...
17:01:24 opendevreview Merged openstack/nova stable/2024.2: restrict swap volume to cinder https://review.opendev.org/c/openstack/nova/+/957762
19:28:25 gibi melwitt: dansmith: responded in https://review.opendev.org/c/openstack/nova/+/942502/13#message-cf59c0d4f875b19c85c544c81fa76210786ca184
19:28:48 gibi unfortunately I had less time today for this than I wanted and I will be away until next Monday.
19:35:02 gibi anyhow I lean towards using the host level default temporarily if possible. I offered some suggestion how.
19:36:24 melwitt thank you gibi. I will read through
19:41:38 dansmith melwitt: I don't have the brain power to think this through completely right now, so let me muse here in semi-persistent land
19:41:51 dansmith something gibi mentioned makes me think...
19:42:15 dansmith we're kinda depending on the scheduler doing the right thing for much of the enforcement of the policy (maybe more than I'd like even, as I noted, but alas)
19:42:37 dansmith maybe the better thing here is to think about the reqspec as the authoritative thing instead of sysmeta
19:43:36 dansmith like maybe we have a default (configurable or just default to host) or we require a policy on the flavor/image for new instances
19:44:02 dansmith and we just stamp it into the sysmeta on the way down
19:44:29 dansmith and handle the migration of existing instances differently.. either:
19:44:55 dansmith 1. stamp them as user and make them resize if they want "out". That's somewhat fitting in that right now the flavor they booted with doesn't have migrate ability, resize to a flavor that does fixes the problem
19:45:34 dansmith 2. make hard reboot pass down a default *or* have some other way for them to stamp a policy (either choice or agree to the default)
19:46:17 dansmith and then just focus on reqspec being the authoritative thing and sysmeta just becomes basically the write-once-read-many record of what was chosen so we know where to find a secret, but never change it (at the compute level)
19:50:40 melwitt I will need to think through these ... and I note that it feels like most of the spec is being rewritten (and the implementation thusly rewritten). not sure if this can realistically make FF :/
19:52:32 dansmith yeah, I know, I was thinking about this earlier too and wondering if we were to ignore the existing instances if we could even just like merge host+user, no hard reboot fix and push some of the details to the end
19:52:59 dansmith the above where we just require resize if you want out of the current limitation might also mean we need to merge less to hit our goal
19:53:14 dansmith and we could follow up with the hard reboot approve-in-place as an optimization
19:53:29 melwitt that's an interesting idea
20:02:14 gibi 1. feel very tempting at first read
20:02:41 gibi resize being the opt in is acceptable to me
20:04:14 gibi and for the cloud admin asking for a reboot or a resize is not a big difference, it is an ask anyhow
20:04:57 gibi also level=user becomes the default which I like :)
20:05:19 melwitt I agree resize opt in sounds reasonable for the first phase in any case
20:15:04 opendevreview Merged openstack/nova master: [tests] Add printing of sample and template paths https://review.opendev.org/c/openstack/nova/+/944054
20:15:55 dansmith resize as the opt-in also lets the admin force them to be moved if they don't want to mix user and host, for example. hard reboot does not give that option
20:44:56 sean-k-mooney does resizeing in this context mean selectign a new flavor with a diffent secreate policy to opt in.
20:45:18 sean-k-mooney im jsut wrapping for the day but i will try to read abck tomorrow if i rememeber
20:45:39 sean-k-mooney oh that the option 1 above
20:47:18 sean-k-mooney to do 1 we woudl ahve to update the isntance copy of the falvor as if the extra spec was set similar to how we often do that to fake the image property being set
20:47:44 sean-k-mooney which is proably ok but i think that a littel trickerer just becasue we store it diffently
20:47:56 opendevreview Merged openstack/python-novaclient master: tests: Stop "testing" against Identity v2 API https://review.opendev.org/c/openstack/python-novaclient/+/952984
20:48:08 sean-k-mooney tirvially so but it woudl be the first tiem to do that with the embeded falvor that i am aware of
20:51:45 melwitt yeah.. I need a moment to regain my bearings 😝 I have spent so much time working on this and implementing the spec. I need some time to re-adjust my mind to this new thing
20:55:14 sean-k-mooney ya i dont have ennoguh sapre brain power to load context and think about this with any depth tonight to say anythign more then "Maybe?"
20:56:17 melwitt heh
20:56:31 sean-k-mooney i vaguly got that dan want to avoid updating the request spec on all move operations which i agree should not be required but i dont knwo why the serisse currenlty is so i cant really comment
20:57:24 melwitt it's because the original design involves setting a default inside sysmeta down in the libvirt driver. so that has to make it to the request spec somehow in order to be honored during scheduling
20:58:04 melwitt this issue goes away if we require image/flavor for the policy, which is why that's being talked about above
20:58:04 sean-k-mooney as in fakign that it was selected in the image medata data
20:58:28 sean-k-mooney so your saying we need to sync the image metadata form teh cell db to the request spec
20:58:35 sean-k-mooney so that move ops fine the right host
20:58:53 melwitt yes pretty much. the entire design in the spec is to put a image_hw_tpm_secret_security into the instance sysmeta regardless of whether it came from an image or not
20:59:08 sean-k-mooney ghat that sound valid and unfortunet because the comptue shoudl nbot need to touch the api db
20:59:16 sean-k-mooney but how do we handel this today?
20:59:27 sean-k-mooney we set a buch fo thing liek that already
21:00:07 melwitt you mean like for AZs? that got brought up in the gerrit review
21:00:28 sean-k-mooney like we set the request for a config drive or the machine tyep when the isntace lands on a comptue node
21:00:45 sean-k-mooney and recored them in instance_system_metadta during spawn
21:02:19 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7190-L7200
21:03:22 sean-k-mooney we do it in other palcees too that just the first palce i found
21:03:46 melwitt yeah that's very similar thing. but I don't find that ever makes it to the request spec
21:04:10 sean-k-mooney there are a bunch of debug lgos when we boot a vm where we recored specific values to make sure they dont change over the lifetime of the vm
21:04:20 melwitt not sure if any of those cases are things that are required for scheduling

Earlier   Later