November 2024 - openstack-discuss

[nova] mdev management for vgpu
by Mickael Razzouk 14 Nov '24

14 Nov '24

Hello, I am tying a few things with vGPU on nova and I struggle with the mdev management Nova does. My environment: - Nvidia A2 pGPU - openstack caracal What I did : - installed the nvidia grid host driver on the compute - enabled the virtual function of the pGPU - added in nova.conf the mdev type wanted and the pci address of the virtual functions - restarted nova - created a flavor with the property resources:VGPU=1 (basicaly followed this documentation : https://docs.openstack.org/nova/latest/admin/virtual-gpu.html) the only diference is that I did not put the pGPU pci address in the nova.conf but the address of its virtual functions, so in my case 0000:41:00.4 and not 0000:41:00.0 (the RP were not detected otherwise) From my understanding of this specs sheet (https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/a…) and some experimentation, When a vgpu is requested by the end user : - Nova looks at the mdevs already running and use them if available. - If there is no mdev available, Nova looks at the RP tree to find mdev capable pci devices that have the specific mdev type available. - If there is such pci device available, Nova create the mdev with a UUID and create the domain XML with this UUID inside. - If no such device is available, Nova returns no host available as an error. My questions are : - Mdev are not persistent across reboot, but when it happens, nova crash at boot because the mdevs are missing, just recreating mdev does not fix the issue as they need to have the same UUID. One could fix the issue by making mdev persistent using a tool like mdevctl, but by creating the mdev the first time I seem to me that Nova tries to manage mdev, is it normal for it to require manual intervention afterward ? Or am I missing something ? - In the nova configuration, is it normal to diverge from the documentation and enter the VF PCI addresses to detect the RF ? Thank you in advance for your help.

4 4

[nova] Spec review day this Thursday 14 Nov 2024
by Sylvain Bauza 14 Nov '24

14 Nov '24

Hey folks, As agreed at the PTG, we'll have a spec review day this week on Thursday. Please mark your calendars for that day as we'll do a first round of spec reviews. Thanks all, -Sylvain

1 1

[OpenInfra Days NA] Recording/Slides from Workshop From zero to code
by Kaster, Jörn 13 Nov '24

13 Nov '24

Hello together, I have seen that on the OpenInfra Days NA there was a Session named 'From zero to code: A hands-on guide to making your first OpenStack code contribution' [1]. Unfortunately I can't attend the OpenInfraDays NA. Now the open question is the following: Is there any Recording/Slides or other Material available? Thank you for any information. [1]https://oidiu2024.sched.com/event/1fH6M/from-zero-to-code-a-hands-on-guid… Mit freundlichen Grüßen / Best Regards i.A. Jörn Kaster Cloud Platform Engineer Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. EPG – Ehrhardt Partner Group EPX Ehrhardt + Partner Xtended GmbH Alte Römerstraße 3 56154 Boppard-Buchholz Germany Phone: (+49) 67 42 / 87 27 0 Fax: (+49) 67 42 / 87 27 50 E-Mail: info(a)epg.com Internet: www.epg.com __________________________________________ CEO: Marco Ehrhardt, Markus Derksen Commercial register Koblenz HRB 22546 Registered office: Boppard

2 1

[ironic] [unmaintained] Retire Bifrost UM? Retire Victoria?
by Jay Faulkner 13 Nov '24

13 Nov '24

Hi all, At the PTG, Ironic cores discussed the state of unmaintained branches in Ironic, this email serves as documentation of this conversation as well as a call to action for anyone who uses (some) unmaintained projects. During this discussion, it was very clear that we believe two things are ready for being fully end-of-life'd: - Bifrost; all unmaintained branches. Bifrost is more of a deployment utility than a service; it takes considerable effort to keep it working past the normal maintenance period. It's the consensus of Ironic cores that all current unmaintained branches for bifrost should be closed, and we should avoid opening them in the future. - Victoria: all projects. There are no longer Ironic core reviewers with vested interest in keeping victoria releases of Ironic (and related projects under BM governance) around anymore. This decision is also informed by the significant effort required to get patches tested against victoria during the recent Ironic OSSAs/CVEs. Since traditionally we have handled our own unmaintained branches, we're making a call for anyone who'd like to keep this alive -- including the current unmaintenance team. This is awkward, because if these were branches Ironic fully controlled we would simply end-of-life them. However, since the idea is for these branches to be able to be maintained without the core teams' interaction, we were going to make this call out. If you have interest in keeping maintenance for these branches, please let us know -- otherwise we will begin efforts to end of life them. Thanks, Jay Faulkner

3 2

[election][all][tc] A call for election officials for 2025.2
by Goutham Pacha Ravi 12 Nov '24

12 Nov '24

Hello Stackers, I'd like to express my gratitude to Ian Y Choi (ianychoi) and Slawek Kaplonski (slaweq) for their service as OpenStack's election officials for the 2025.1 term. A hallmark of our community has been its leadership and the guiding principles [1] we use when defining them. In Feb-Mar 2025, we're going to be electing the next set of OpenStack Project Team Leads as well as 5 members of the OpenStack Technical Committee. We've run a combined election for PTLs and TC seats in the past few years. We envision doing the same for this upcoming election. Most of the election process is automated, and election officials help execute and oversee this process [2]. If you're interested in being an election official, please reach out to me. If you've previously served as an election official, please do not hesitate to reach out. If we have enough volunteers, you may do us a great favor by mentoring those doing this for the first time. Thank you, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://governance.openstack.org/tc/reference/principles.html [2] https://governance.openstack.org/election/process.html

1 0

[OpenStack-Ansible] Major Upgrade from Yoga to Zed/Antelope
by Roby G 12 Nov '24

12 Nov '24

Hello everyone, Current environment: - Ubuntu 20.04 - OpenStack-Ansible Yoga - no LXC, services are installed bare metal - `install_method` is `distro` My goal is to upgrade this environment to Zed, or skip Zed and upgrade directly to Antelope, since Zed is also in Unmaintained state. What would you recommend? Which order should I follow - upgrade operating system or OpenStack first? The decision is a bit difficult as all 3 releases (Yoga, Zed and Antelope) support different Ubuntu versions in install_method distro and not the same one.

2 1

[kolla-ansible]: guidance needed for neutron setup
by turkey automation 12 Nov '24

12 Nov '24

Hey folks, I am new to Openstack and want to try it on KVM setup with 1 controller and 2 compute VMs. In my first attempt, I was able to install Openstack using kolla-ansible(2024.1 version) and also run-initonce completed without any issues. Now, I want to create instances that can access my back-bone i.e. KVM virtual network(192.168.121.x/24) but either floating IP concept or extending my KVM network to openstack(I don't know if it's feasible!) Some info about my infra: a. Controller 1: Interface eth0 has 192.168.121.5 IP address. eth1 has no IP. b. compute 1: Interface eth0: 192.168.121.10, eth1 has no IP. c. compute 2: interface eth0: 192.168.121.15, eth1 has no IP. What configuration do I need to enable in globals.yml and what all I need to do post deployment of openstack to ensure I have virtual instances on openstack that have IPs from 192.168.121.x network(dhcp can be controlled by KVM network?) and are accessible from other KVM based VMs that I created outside of openstack. I am a learner to please be elaborate if possible. Thanks in advance to the community. - Best regards!

3 6

Upstream Oslo IRC Meetings Are Back.
by Daniel Bengtsson 12 Nov '24

12 Nov '24

Hello everyone, I hope you are all doing well! I sent an email a while ago to reestablish the Upstream Oslo IRC meetings. With the removal of Eventlet, this makes even more sense. I have received two positive responses, and we also mentioned it during the PTG last week. I propose to hold these meetings every other Monday, starting today, at 4:00 PM UTC. Does this work for everyone? Thank you for your feedback! -- Daniel Bengtsson Software engineer

6 18

Oslo Meeting day and agenda.
by Daniel Bengtsson 12 Nov '24

12 Nov '24

Hi everyone, I hope you’re doing well! As a reminder, we’ve chosen the day and time for the Oslo meetings. They will take place every Wednesday with the following schedule: • Even weeks: Europe/US • Odd weeks: Europe/Asia I’ve proposed a patch[1] to update the meeting times. We’ll also have a meeting tomorrow at 13:00 UTC. The topic for tomorrow will be the proposed removal of Eventlet[2] in Oslo service. To help track our meetings, I’ve created an Etherpad document[3], which you can view here: Oslo Etherpad. I used the release structure as inspiration, keeping only the essentials for Oslo. Thanks, and see you tomorrow! [1] https://review.opendev.org/c/opendev/irc-meetings/+/934648 [2] https://review.opendev.org/c/openstack/oslo-specs/+/927503 [3] https://etherpad.opendev.org/p/epoxy-oslo-meeting-tracking -- Daniel Bengtsson Software engineer

1 0

#eventlet-removal - OFTC IRC meeting time slot poll - Express your choice!
by Herve Beraud 12 Nov '24

12 Nov '24

Hey Stackers, We propose to schedule a one hour OFTC IRC meeting (#opentack-eventlet-removal) each first and third week of each month. Let's find together the right UTC time slot for our one hour OFTC IRC meeting. Once the vote is done, meetings will be scheduled each first and third <selected time slot in the poll> of each month. Please, vote here: https://framadate.org/rUghO3j6ZkRhKD7m Votes will be considered as closed by Nov. 8th First meeting will be forced to 4pm UTC on Tuesday Nov 5th and then moved to the selected time slot for all the following meetings. See the proposed time slots in the poll link above. Join us on the #opentack-eventlet-removal OFTC IRC channel. Thanks in advance for your votes -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 2