| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-04-29 | |||
| 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 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-04-29-16.01.log.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 | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-04-29-16.01.html | |
| 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 | bauzas | #endmeeting | |
| 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 | |
| 17:05:26 | sean-k-mooney | but im not sure if thaty is what they ment about hypervior above | |
| 17:05:40 | dansmith | like requesting something libvirt- or vmware-specific that just makes the scheduler not even willing to send it to another host, etc | |
| 17:05:47 | sean-k-mooney | oh no it is | |
| 17:05:51 | dansmith | right | |
| 17:06:20 | sean-k-mooney | anyway i guess they may have jost wanted to avoid a spec initall to get some high level input | |
| 17:06:28 | sean-k-mooney | i.e. is this somethign we woudl ever want to supprot | |