| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-13 | |||
| 16:14:15 | sean-k-mooney | if they have not had one already | |
| 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 | |