Earlier  
Posted Nick Remark
#openstack-nova - 2025-05-13
16:14:38 elodilles sean-k-mooney: release patches are already generated where were (functional) code changes
16:14:47 sean-k-mooney ack
16:14:56 Uggla masahito, soft spec is deadline to submit spec
16:15:13 Uggla spec freeze is deadline to merge the spec
16:15:51 elodilles sean-k-mooney: with a quick check i don't see any nova related flamingo-1 release patch ( https://review.opendev.org/q/topic:flamingo-milestone-1 )
16:16:02 masahito got it. i understand i need to submit the spec and poc code quickly.
16:16:57 sean-k-mooney elodilles: we definally have had some functional changes. althogu i know for os-trait for one we already had at least 1 release
16:17:21 Uggla masahito, mainly the code.
16:17:25 Uggla oops
16:17:38 Uggla sorry mainly the spec
16:17:41 sean-k-mooney masahito: you tecnially can submit a spec after the soft freeze but the later you do the more risk peole will run out of time to review
16:18:16 elodilles sean-k-mooney: that is 'cycle independent' project, so that one is not closely followed by release team
16:18:29 masahito thanks
16:18:45 sean-k-mooney elodilles: ack, we can likely move on to the next topic?
16:18:55 elodilles sean-k-mooney: ++
16:20:00 Uggla sean-k-mooney, elodilles question should I propose a release patch for os-trait ?
16:20:51 bauzas that's an independent
16:20:56 bauzas no need
16:20:57 elodilles Uggla: there is no deadline for os-traits to Flamingo-1, but it can be proposed any time you want
16:21:25 Uggla ok thx I just wanted to be sure.
16:21:25 bauzas i mean independent release cadence
16:21:50 Uggla #topic Review priorities
16:21:59 Uggla #link https://etherpad.opendev.org/p/nova-2025.2-status
16:22:00 elodilles on the other hand it's good to release when there are merged patches, so that it won't be forgotten during the cycle o:)
16:22:12 bauzas Uggla: I could show you up where to find the release models for each of the projects we have in OpenStack
16:22:29 sean-k-mooney i know mstill would like to do one for the vdi stuff but we can just do that out of band
16:23:10 Uggla Just to let you know the the title of the channel was changed to point to the correct document
16:23:18 sean-k-mooney i.e. we have a reqeust to do a release but we dont need to do one proceudrlly on any deadline we just should to unblock them
16:23:58 sean-k-mooney Uggla: yes i want to add an opendicssion topic related to that btu we can talk about that when we get there
16:24:37 Uggla ok
16:24:44 Uggla #topic Stable Branches
16:24:50 Uggla time for you elodilles
16:24:57 elodilles o7
16:25:04 elodilles #info stable branches (stable/2025.1 and stable/2024.*) seem to be in OK state
16:25:10 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:25:19 elodilles that's all from me
16:25:39 Uggla cool thx
16:25:42 Uggla #topic vmwareapi 3rd-party CI efforts Highlights
16:25:50 Uggla fwiesel, anything special ?
16:25:51 fwiesel No updates from my side.
16:26:03 Uggla thx
16:26:11 Uggla #topic Gibi's news about eventlet removal.
16:26:18 Uggla #link Series: https://gibizer.github.io/categories/eventlet/
16:26:26 gibi latest blog post is https://gibizer.github.io/posts/Eventlet-Removal-The-First-Threading-Bug/
16:26:27 Uggla #link reminder patches to review: https://review.opendev.org/q/topic:%22eventlet-removal%22+project:openstack/nova
16:27:02 gibi working on cleaning up the nova-scheduler series
16:27:31 gibi review is appreciated on https://review.opendev.org/c/openstack/nova/+/948437?usp=search
16:27:42 gibi and on https://review.opendev.org/c/openstack/nova/+/948437?usp=search
16:27:50 gibi I mean https://review.opendev.org/c/openstack/nova/+/948437?usp=search
16:28:00 gibi somebody break my copy paste buffer :)
16:28:03 bauzas I so would like to help reviewing
16:28:12 bauzas I'll ty to find some time
16:28:16 gibi https://review.opendev.org/c/openstack/nova/+/947265
16:28:21 gibi https://review.opendev.org/c/openstack/nova/+/948437
16:28:24 gibi the two patches to land
16:28:35 gibi the long series is not ready but working on it
16:28:36 sean-k-mooney 37 is pretty short so i can proably look at that after the meeting
16:28:50 gibi that is all from me
16:28:56 sean-k-mooney and the hacking one i gues
16:29:02 gibi yepp
16:30:01 Uggla #topic Open discussion
16:30:21 fwiesel That would be my topic, I suppose.
16:30:23 Uggla fwiesel, can you go ahead with your topic
16:30:25 fwiesel Support for libvirt VIR_MIGRATE_PARAM_PARALLEL_CONNECTIONS
16:31:03 fwiesel So, since QEMU 2.11 and libvirt 5.2.0 there is support for using multiple threads in the precopy operation.
16:31:03 sean-k-mooney oh :) that could be useful
16:31:20 fwiesel I was wondering, if I can just to a specless blueprint for that?
16:31:50 sean-k-mooney i think that would be supported by our min qemu/libvirt versions
16:32:12 sean-k-mooney so it would really just be a config option to allow enabling it
16:32:16 sean-k-mooney and perhaps dicussing if it should be on or off by defualt
16:32:29 gibi would it be a compute config param to enable? Does it only need to be enabled on the source node?
16:32:41 Uggla I think because it require a config option a small spec will be worth it.
16:32:57 sean-k-mooney this is really only useful if you have more bandwith aviable on the migration link then a singel core can saturate.
16:33:01 fwiesel Ah, so a spec. I can do that
16:33:18 fwiesel Yes, we need roughly 12 threads to saturate our 200GigE links.
16:33:21 sean-k-mooney well it could be specless maybe but yes i blive this need to be set on the source
16:33:33 Uggla yes so we can bikeshed on the config name. :)
16:33:50 sean-k-mooney like the other migration parmaters i dont think it can be changed once the migration is started and that is done form the source node
16:34:39 Uggla sean-k-mooney, this is a parameter to pass to migrateToURI3, if I'm not wrong.
16:34:42 sean-k-mooney fwiesel: based on that math if you have a 25G link or grather you would benifit form this
16:34:52 sean-k-mooney Uggla: yes i belive it is
16:35:17 gibi Thanks. I'm OK with a specless but fine with a spec too
16:35:18 Uggla sean-k-mooney, I looked quickly before the call.
16:35:46 sean-k-mooney i belvie we were asked about this either in the ptg or on irc shourtly before it too
16:35:50 Uggla I think the spec is cool to discuss names and defaults
16:36:14 Uggla sean-k-mooney, more or less this is from masahito but this is another settigns
16:36:33 sean-k-mooney i think it makes sense to do so sepless or small spec is ok with me
16:36:44 sean-k-mooney *specless or a small spec
16:36:55 sean-k-mooney we can debate the name in the gerrit review
16:36:57 fwiesel The consensus seems then a small spec?
16:37:06 sean-k-mooney presumable its a new option in the libvirt section
16:37:15 bauzas I'd say that depends on the default value
16:37:32 sean-k-mooney like https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.live_migration_inbound_addr
16:37:36 bauzas meaning whether we would have upgrade concerns
16:37:38 fwiesel I'd gone with a default that keeps the old settings.
16:37:46 fwiesel So, it is opt-in
16:38:03 sean-k-mooney if we default to off. i dont think there would be an upgrade concern
16:38:13 sean-k-mooney and we can consider changing the default in 2026.2+
16:38:25 bauzas yup so then I specless works for me
16:38:27 sean-k-mooney we proably shoudl test it in nova-next

Earlier   Later