Earlier  
Posted Nick Remark
#openstack-nova - 2025-04-29
16:09:13 bauzas #topic Review priorities
16:09:13 bauzas #link https://etherpad.opendev.org/p/nova-2025.2-status
16:09:20 bauzas elodilles +1d
16:09:30 gibi elodilles: +1d
16:09:45 bauzas apparently Uggla did a work on creating a tracking etherpad, noice
16:10:06 bauzas #topic Stable Branches
16:10:07 elodilles thanks all o/
16:10:13 bauzas elodilles: shoot your topic
16:10:25 elodilles ah, ok
16:10:36 elodilles #info not aware of any stable gate blocking thing
16:10:58 elodilles i haven't seen any setuptools related issue yet :)
16:11:17 elodilles but there were not much activity in the past days
16:11:21 elodilles #info stable/2023.2 (bobcat) EOL patch for nova: https://review.opendev.org/c/openstack/releases/+/948196
16:11:39 elodilles another patch that needs some nova release liaison review ^^^
16:11:49 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:11:56 elodilles that's all from me
16:12:00 elodilles bauzas: back to you
16:12:28 bauzas cool
16:12:39 bauzas #topic vmwareapi 3rd-party CI efforts Highlights
16:12:43 bauzas fwiesel: around ?
16:12:47 fwiesel Yes, finally.
16:12:54 fwiesel #info fwiesel reports back to duty
16:12:56 fwiesel So to say
16:13:10 fwiesel #info fwiesel will involve more people from SAP for redundancy
16:13:44 fwiesel When I had my sick leave, I just dropped a short message on slack, hoping someone will take over, but that didn't work.
16:13:50 fwiesel I'll try to make that more formal.
16:13:54 fwiesel That's from my side.
16:13:59 bauzas cool
16:14:08 bauzas #topic Gibi's news about eventlet removal.
16:14:10 bauzas gibi: shoot
16:14:16 gibi ack
16:14:31 gibi we saw the first nova-scheduler run with native threading
16:14:43 gibi actually multiple green CI jobs
16:14:49 gibi e.g. https://zuul.opendev.org/t/openstack/build/636bdbb6ad494ef0b49415034842a640/log/controller/logs/screen-n-sch.txt nova-multi-cell
16:15:23 gibi nothing needs immediate review attention. The ball is on my side to clean up the series that is open
16:15:46 gibi that is it
16:16:27 gibi bauzas: back to you
16:16:30 bauzas noted
16:16:53 bauzas I'll skip the bug scrub as I don't have time to lead this
16:17:01 bauzas and given Uggla is on PTO
16:17:08 bauzas #topic Open discussion
16:17:12 bauzas anything anyone ?
16:17:42 fwiesel Yes, me then.
16:18:23 fwiesel I was curious about what you think about enabling resize between hypervisors? I mean, a full discussion obviously means a blueprint.
16:18:40 bauzas I'll need to disappear shortly
16:18:53 bauzas do people have opinions about ^ ?
16:18:55 gibi fwiesel: yeah probably a spec
16:19:18 bauzas not sure what you mean by an "hypervisor resize"
16:19:20 fwiesel Question there is is it worthwile to open one
16:19:38 bauzas resizing all the instances on that host ?
16:19:52 fwiesel Ah, the idea is we have a flavor for one hypervisor (i.e vmware), and the user wants to migrate to another one, say libvirt.
16:20:04 bauzas or some hardware change for an hypervisor, like a new memory card ?
16:20:08 fwiesel The user can then call a resize from one flavor to another
16:20:23 bauzas ah
16:20:44 bauzas we don't bubble up that to the users because $cloud
16:21:00 fwiesel I can write a spec, but I wanted to know if anyone would even be willing to look at it :)
16:21:04 bauzas but, operators can do multiple scheduling usages for that
16:21:19 bauzas eg. aggregates, traits or anything else decorating
16:21:45 bauzas not sure I want to disclose which hypervisor runs by a flavor
16:23:02 fwiesel Let's turn it the other way around. Is it desireable that a resize should work between two different nova drivers?
16:23:19 bauzas I need to go offline now
16:23:27 bauzas again, anyone want to discuss this ?
16:23:35 bauzas or we could discuss this next week
16:23:42 gibi fwiesel: at least it worth dicussing it. I'm not against it at a first glance
16:24:18 fwiesel I can bring it up next week again. I want to avoid writing a spec, if there is a strong opposition to it.
16:25:12 bauzas thanks, let's then discuss this again nextweek
16:25:16 bauzas thanks all
16:25:21 bauzas #endmeeting
16:25:21 opendevmeet Meeting ended Tue Apr 29 16:25:21 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:25:21 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-04-29-16.01.html
16:25:21 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-04-29-16.01.txt
16:25:21 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-04-29-16.01.log.html
16:25:22 fwiesel thanks everyone
16:25:59 elodilles thanks o/
16:26:04 gibi fwiesel: yeah I understand that you don't want a full blown spec. Maybe start a spec and only fill the up until the Use Case section
16:26:34 gibi so define the what and keep the how empty
16:26:42 gibi what and why
16:27:25 gmaan bauzas: latest-microversion job in periodic- https://review.opendev.org/c/openstack/tempest/+/948458
16:39:36 opendevreview Dan Smith proposed openstack/nova master: WIP Example NVMe cleaning script for one-time-use https://review.opendev.org/c/openstack/nova/+/948446
16:45:34 melwitt gibi: cool thanks for fixing it!
16:56:42 sean-k-mooney if by resize between diffent hyperviors that actully means between differnt virt driver then that woudl need a full spec
16:57:07 sean-k-mooney because that bring up the qustion what do you do with things like the disk format
16:57:45 sean-k-mooney even if we do it via shelve liek we do for cross cell i expect there to be dragons
17:02:19 dansmith on the one hand, it shouldn't be a problem at all,
17:02:41 dansmith except for the disk format, the metadata that might make it not a candidate for the other hypervisor, etc
17:02:51 dansmith so I expect there are dragons, but not fundamental ones
17:03:01 sean-k-mooney well even simple things like libvirt expect to be able to scp the disks
17:03:04 dansmith either way, I'm not sure how anyone could argue that a spec isn't warranted :)
17:03:17 sean-k-mooney im sure vmware/hypver/ironic woudl have optinons about that
17:03:35 dansmith sean-k-mooney: I meant for the shelve-based approach, which I think would be the best for something
17:03:40 dansmith like cross-cell resize does
17:03:45 sean-k-mooney oh right
17:04:06 sean-k-mooney ya shelve is likely mortly ok
17:04:25 sean-k-mooney althoguh windows may be unhappy if the mosther board that is virutalise and all the periferals
17:04:36 sean-k-mooney change form whatevver vmware provides to q35
17:04:54 dansmith sure, that's all under the metadata umbrella I meant above
17:05:00 sean-k-mooney ah
17:05:08 sean-k-mooney i tought you ment the instnace metadata
17:05:16 sean-k-mooney but ya liek it might work
17:05:24 dansmith no, image meta

Earlier   Later