| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-04-29 | |||
| 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 | |
| 17:06:54 | sean-k-mooney | i dont think its unreasonable but alos not a high on my wishlist | |
| 17:06:55 | dansmith | hard to say if we could/would without knowing the dragons, which is what a spec is for :D | |
| 17:07:00 | dansmith | agreed | |
| 17:07:17 | sean-k-mooney | if you had a vmware backed openstack | |
| 17:07:24 | dansmith | I wonder if the ask is coming from an escape-the-20x-license-increase thing | |
| 17:07:31 | sean-k-mooney | and wanted to move to libvirt i guess it woudl be nice to jsut rezie the vms to do that | |
| 17:07:34 | dansmith | there are also community and commercial migration functions, so.. | |
| 17:08:15 | sean-k-mooney | ya that what im wondering too because fwiesel has been trying to maintain the vmware dirver bcause sap use it internally | |
| 17:08:35 | sean-k-mooney | so this may be realted to enabling them to move to libvirt goign forward | |
| 17:08:59 | sean-k-mooney | so migratekit or os-migrate might help there | |
| 17:10:04 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP : Add mtty support to nova-next https://review.opendev.org/c/openstack/nova/+/922140 | |
| 17:10:04 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add mtty/mdpy support for testing fake mdevs https://review.opendev.org/c/openstack/nova/+/898100 | |
| 18:28:45 | opendevreview | Merged openstack/nova master: Remove python 3.9 support https://review.opendev.org/c/openstack/nova/+/948392 | |
| 19:43:13 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove tags from README https://review.opendev.org/c/openstack/placement/+/941792 | |
| 19:43:22 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove tags from README https://review.opendev.org/c/openstack/placement/+/941792 | |
| 19:43:25 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove tags from README https://review.opendev.org/c/openstack/placement/+/941792 | |
| 19:43:48 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove tags from README https://review.opendev.org/c/openstack/placement/+/941792 | |
| 19:47:03 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove tags from README https://review.opendev.org/c/openstack/placement/+/941792 | |
| 22:13:18 | opendevreview | sean mooney proposed openstack/nova master: Add admin docs to cover limitations of OTU devices https://review.opendev.org/c/openstack/nova/+/948492 | |
| 22:15:49 | sean-k-mooney | dansmith: i have tired to capture some fo the design constratis and limiation around OTU device and what a cleaning script, process shoudl do in terms of pre/post constratis | |
| 22:16:46 | sean-k-mooney | dansmith: ^ im not sure if you had anything similar planned as a follow up but hopefully this will be useful for folks. | |
| 22:17:19 | sean-k-mooney | i have tired to spellcheck it but i dint pass it though grammerly. hopefully it pretty readable | |
| 22:19:17 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove tags from README https://review.opendev.org/c/openstack/placement/+/941792 | |
| 22:26:27 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove tags from README https://review.opendev.org/c/openstack/placement/+/941792 | |
| 22:26:35 | opendevreview | Ivan Anfimov proposed openstack/placement master: Remove tags from README https://review.opendev.org/c/openstack/placement/+/941792 | |
| #openstack-nova - 2025-04-30 | |||
| 08:34:34 | opendevreview | Sylvain Bauza proposed openstack/nova master: WIP : Add mtty support to nova-next https://review.opendev.org/c/openstack/nova/+/922140 | |
| 08:34:34 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add mtty/mdpy support for testing fake mdevs https://review.opendev.org/c/openstack/nova/+/898100 | |
| 09:38:32 | opendevreview | LiuWenYu proposed openstack/nova master: Implements: Fixed the issue where the code logic would throw an error when reading a variable after NUMA node 0’s CPUs were fully utilized. Related-Bug: #2109675 https://review.opendev.org/c/openstack/nova/+/948540 | |
| 09:47:49 | gibi | sean-k-mooney: the generic env passing logic works nicely here https://review.opendev.org/c/openstack/nova/+/948450/2 with the devstack patch https://review.opendev.org/c/openstack/devstack/+/948436 So now we can selectively turn on threading mode per service from the zuul job config. | |
| 11:06:50 | elodilles | auniyal bauzas Uggla : hi, sorry for pinging you, but could you take a look at the 2023.2 Bobcat EOL patch of nova please: https://review.opendev.org/c/openstack/releases/+/948196 | |
| 11:07:02 | elodilles | it would be nice to have an ACK from the team o:) | |
| 11:07:08 | elodilles | i've checked and hashes are still all correct | |
| 11:34:43 | sean-k-mooney | gibi: awsome that was also much smaller then i was expecting | |
| 11:35:46 | sean-k-mooney | 'SYSTEMD_ENV_VARS["n-sch"]': OS_NOVA_DISABLE_EVENTLET_PATCHING=true | |
| 11:36:31 | sean-k-mooney | a i see wll thats a little bit of a wart but i guess when your are rendering a local.conf via yaml | |
| 11:36:38 | sean-k-mooney | via ansible | |
| 11:36:56 | sean-k-mooney | that less bad then it could have been | |
| 11:37:44 | sean-k-mooney | so in this version nova-next is the only job using the new code path | |
| 11:37:55 | sean-k-mooney | i guess it make sense to use that as our canary job | |
| 11:47:58 | gibi | yeah | |
| 11:48:20 | gibi | I think I will duplicate nova-multi-cell to have a threading variant eventually as well | |
| 11:48:38 | gibi | but for now nova-next is good enough | |
| 12:48:09 | sean-k-mooney | zigo: i dont know if this is just a ubunut issue or also a debian issue but novnc is declared as requiring phty3-novnc which requires python3-oslo.confing. however as far as i can tell that depency was removed in 0.6.0 when they deleted there vendro copy of nova vnc proxy, novnc does not seam to have any python deps any more and is basiclly pure javascript | |
| 12:48:48 | bauzas | gibi: sean-k-mooney: I had no time in between yesterday and today to look at the scheduler eventlet series, anything you want me to know ? | |