November 2024 - openstack-discuss

[FOSDEM] Reminder about call for participation - Virtualization and Cloud infrastructure Room 2025
by Piotr Kliczewski 17 Nov '24

17 Nov '24

All, This yeah submission deadline is enforced for all devrooms so this year our due date is on 1st of December not as all previous years on 8th. This is our gentle reminder to submit [0] your proposals. See you soon at FOSDEM! [0] https://fosdem.org/submit

1 0

[ironic] PTG Summary and Workitems for 2025.1
by Jay Faulkner 15 Nov '24

15 Nov '24

Hi all, The Ironic team, as usual, has whittled our PTG notes down into a document describing the items we'll be focusing on this cycle. The usual disclaimer applies: this is open source, and we're talking about what we /want/ to do, not making any promises about what /will/ be done. The document can be found at https://specs.openstack.org/openstack/ironic-specs/priorities/2025-1-workit…. I hesitate to include this in the same email; because that ^ document is semi-official and this is not; but I also made a short video describing these priorities if you prefer that medium; https://www.youtube.com/watch?v=oy25mATgbrY Thanks to everyone in the Ironic community for an awesome PTG, and a special thanks to our PTL Riccardo for doing an excellent job organizing and moderating it. Thanks, Jay Faulkner

1 0

[ec2-api][kuryr][murano][sahara][senlin][solum][winstackers] Move 2023.1 Antelope and older branches to End of Life
by Elõd Illés 15 Nov '24

15 Nov '24

Hi, The projects in $SUBJECT are retired projects without any activity or maintenance for some time now. That is why instead of moving their stable/2023.1 (antelope) branch to Unmaintained we plan to directly move them to End of Life. To be able to do that we also have to move older branches to End of Life and delete them too. We don't expect any objection, but if someone wants to step up and bring these projects back to life, then this is the last chance before we move them to End of Life. Thanks, Előd Illés irc: elodilles @ #openstack-release

2 1

[release] Release countdown for week R-19, Nov 18 - 22
by Elõd Illés 15 Nov '24

15 Nov '24

Development Focus ----------------- We are now past the Epoxy-1 milestone. Teams should now be focused on feature development and completion of goals [0]. [0] https://governance.openstack.org/tc/goals/selected/index.html General Information ------------------- Our next milestone in this development cycle will be Epoxy-2, on January 9th, 2025. This milestone is when we freeze the list of deliverables that will be included in the 2025.1 Epoxy final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/epoxy directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- Epoxy-2 Milestone: January 9th, 2025 2025.1 Epoxy final release: April 2nd, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

CLI or Steps to find installed OpenStack version
by Manohar Kundapura (makundap) 15 Nov '24

15 Nov '24

Hi All, Looking for the steps to find out which release/version of OpenStack from the below link, is installed on a Server. https://releases.openstack.org/ Thanks, Manohar

3 2

[horizon] SCSS compilers
by Radomir Dopieralski 15 Nov '24

15 Nov '24

The openstack dashboard uses scss for styling, and so far we have used a python scss library for compiling those files to css for use in the browser. However, that library (pyscss) had in recent years some problems, and is not developed or supported by the authors anymore. So it's time to switch to something with a better support. The django-compressor plugin that we use for handling the compilation of files allows us to use any command-line tool to do the compilation, so we can switch to an scss compiler that is supported and used by the wider community. However, there are several options we can choose from: sassc python-libsass pysassc ruby-sass ruby-sassc node-node-sass Each of those would introduce a non-python dependency on the dashboard. The question for the packagers and distro maintainer is which of those tools would be preferable in terms of support, packaging, and maintenance for the long term? Do you have opinions? Maybe there is another tool that would be even better that I didn't find?

2 3

[neutron] Drivers meeting agenda for Friday, November 15th
by Brian Haley 14 Nov '24

14 Nov '24

Hello Neutrinos: Sorry for the late notice but this is the agenda for tomorrow's drivers meeting: * Configurable Agent Termination on OVS Restart * https://bugs.launchpad.net/neutron/+bug/2086776 * There has been good discussion in this bug from Liu * L3 Agent Readiness Status for HA Routers * https://bugs.launchpad.net/neutron/+bug/2086794 * OVS Agent Synchronization Status for Container Environments * https://bugs.launchpad.net/neutron/+bug/2086799 - related to 2086794 * Add OVN Ganesha Agent to setup path for VM connectivity to NFS-Ganesha * https://bugs.launchpad.net/neutron/+bug/2087541 Unfortunately I will not be able to attend due to a last-minute conflict, so if someone else could lead the meeting I would appreciate it, otherwise we will postpone until next Friday. -Brian

1 0

[watcher] unmaintained branch cleanup
by Sean Mooney 14 Nov '24

14 Nov '24

Hi everyone, As some may now we are currently trying to revive the maintenance of the watcher project, i have volunteered to be the release liaison for the project. At the ptg a few weeks ago we briefly discussed the state of the unmaintained and stable branches watcher currently had 5 unmaintained branches from the oldest unmaintained/victoria <https://opendev.org/openstack/watcher/src/branch/unmaintained/victoria> to the newly created unmaintained/2023.1 <https://opendev.org/openstack/watcher/src/branch/unmaintained/2023.1> https://opendev.org/openstack/watcher/branches since the unmaintained branches have been create, they have not received any meaningful patches, including in some cases the auto generated patches from our openstack patch bots. during the ptg i proposed moving all unmaintained branches older than 2023.1 to end of life. recently https://review.opendev.org/c/openstack/releases/+/935041 has been proposed to "Transition zed-eom branches to EOL" which aligned to my proposed plan for watcher. Per the ptg discussion i committed to reaching out via the mailing list to see if there was any objection to this plan https://etherpad.opendev.org/p/r.79644f8f3cd04686c4f45c10aa35d8ac#L79 please respond here or on https://review.opendev.org/c/openstack/releases/+/935041 if you have an objection to the unmaintained branch transition. regards sean

1 0

[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