- openstack-discuss - lists.openstack.org

[horizon] Considering a change in how SCSS styles are handled
by Radomir Dopieralski 19 Nov '25

19 Nov '25

Hello everyone, while working on some other part of Horizon, I recently looked at the source of the pages generated, and noticed that a substantial amount of each page is the style, compiled and included on every single page using the <style> tags. That is a rather bad practice for a number of reasons, from performance to waste of bandwidth. I decided to see if that could be easily fixed, so prepared this patch that instead includes the compiled style using a <link> tag: https://review.opendev.org/c/openstack/horizon/+/966665 Now, I'm writing to this list for two reasons. The first is to make sure that there isn't some rule or regulation, possibly introduced before the Web was invented, that requires all OpenStack software to handle the styles in that way, and that we would be breaking if we went with my patch. The second is of a more technical nature, and pertains to the change that had to be made to the `_components.scss` file in that patch. In short, a similar change would have to be done in any Horizon plugin that adds style sheets to `HORIZON_CONFIG.scss_files`. Since we don't have control over Horizon plugins and can't possibly force such a change, and since merging my patch without such changes would break the plugins, I would like to hear from the plugin maintainers about the best way to proceed with this (or, just leaving things as they are, if that is the better option). The change becomes necessary, because the included `scss_files` can no longer be compiled in one huge block with the rest of horizon's styles, but have to be included with their own <link> tags as separate files, which means that any dependencies they rely on have to be explicitly included using the `@import` mechanism. Most of those styles at the minimum will rely on the common variables from the theme, that's why this particular import, but there may be a need for more imports added depending on what the stylesheet in question uses. I'm also open to suggestions on how to avoid the need for this change and compile everything in one big blob as we are doing now, but don't inline the style on every page. Between Django, Django-compressor, SCSS compiler and template mechanism, I don't currently see a way to do this. Thank you for your feedback, -- Radomir Dopieralski

2 1

[cinder] festival of reviews friday 2025-11-21
by Brian Rosmaita 19 Nov '25

19 Nov '25

Hello Argonauts, This is a reminder that the most recent edition of the Cinder Festival of Reviews (no longer extra-small!) will be held at the end of this week on Friday 21 November. who: Everyone! what: The Cinder Festival of Reviews when: Friday 21 November 2025 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics (though for some reason, the november 2025 meetings don't show up) See you there!

1 0

GPU card for multiple users
by KK CHN 19 Nov '25

19 Nov '25

List, I am having NVIDIA L40s, PCle GPU installed in one of Ubuntu Server Box, How can I make use this NVIDIA L40s card to support multiple users for running their AI work loads. How to achieve this virtualization support for the NVIDIA Card. Some body can shed some light on this regard , what are the steps need to perform to get the GPU card virtualized ? Thanks in advance, Krishane

2 2

[2023.1][kolla][rabbitmq] Failing to get packages from RabbitMQ Repos
by Rob Jefferson 18 Nov '25

18 Nov '25

Folks, At work, we're using Kolla 2023.1, and during a recent build, I saw that the PPA that provided RabbitMQ packages gave me a "402 Payment Required" error. This seems to be an existing problem, so I decided to try using the PPA that's in the current version of 2023.1 Kolla. When I change the repo in `kolla/templates/repos.yml` so that the URL is https://ppa1.rabbitmq.com/rabbitmq/rabbitmq-server/deb/ubuntu and the key in `docker/base/Dockerfile.j2` to be 9F4587F226208342, I get the following error: > E: The repository 'https://ppa1.rabbitmq.com/rabbitmq/rabbitmq-server/deb/ubuntu jammy Release' does not have a Release file. If, on the other hand, I use the PPA in the official RabbitMQ docs: https://deb1.rabbitmq.com/rabbitmq-erlang/ubuntu/jammy And use the key 0A9AF2115F4687BD29803A206B73A36E6026DFCA, I get the following error: > W: GPG error: https://deb1.rabbitmq.com/rabbitmq-server/ubuntu/jammy jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 6B73A36E6026DFCA > INFO:kolla.common.utils.rabbitmq:E: The repository 'https://deb1.rabbitmq.com/rabbitmq-server/ubuntu/jammy jammy InRelease' is not signed. In both cases, I'm not sure what the issue is. I would have expected RabbitMQ server for Jammy to still be available in the first case (especially since that PPA remains in Kolla), or for the key I used in the second case to exist. Is there something I can try to fix this issue? Thanks, Rob

4 4

Updating Monitor List (rbd section) using Virsh with no downtime
by m.riudalbas＠first-colo.net 18 Nov '25

18 Nov '25

Hello, is there a way to update a monitor list of the rbd section in a virtual machine? We need to add or modify the following entries. <source protocol='rbd' name='cinder/volume-343766ad-0086-4f8c-a557-bc60ba2210f4' index='1'> <host name='172.16.65.164' port='6789'/> <host name='172.16.65.165' port='6789'/> <host name='172.16.65.166' port='6789'/> </source> We want to replace the Monitor network and this means that we have to update every virtual machine with the new Ceph monitor IPs. The only way to replace them is with a live migration (then the live ceph configuration with the new IPs will be applied), but we would like to know if there is a faster way (because we have approximately 200-300 VMs) and some of them are so big that a live migration is impossible (only an offline migration could be done, resulting in a downtime). Another way to refresh the list is detaching the volume, but this only works for non-bootable volumes. We tried modifying the virsh XML directly (virsh edit ...) and creating a separate XML file and applying it with "virsh define newfile.xml", but the list will not be updated. Many thanks in advance!

2 1

[qa][ops] Light-weight guest image for UEFI boot and secure boot
by Takashi Kajinami 18 Nov '25

18 Nov '25

Hi, I've been trying to implement a few tempest tests to verify functionality of UEFI boot and secure boot, and I noticed that cirros, which is used as a primary guest image for tests, do not support UEFI boot. I'm wondering if anyone can share a good light-weight guest image used in their own tests of these features ? I guess that ubuntu guest image might be a primary choice (given the fact that ubuntu is the default operating system for tests) but I'm wondering if we have more light-weight one. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

5 7

[publiccloud-sig] Public Cloud SIG meeting d.d. 19 November
by Kees Meijs | Nefos 18 Nov '25

18 Nov '25

Hello Stackers, Tomorrow (that's 19 November) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:05 hrs UTC (09:05 hrs CET) until 08:55 hrs UTC (09:55 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 0

[tc][tripleo] About os-net-config
by Goutham Pacha Ravi 17 Nov '25

17 Nov '25

Hello Stackers, I am writing to seek clarity regarding recent activity on the PyPI project for os-net-config [1]. As you can tell, "OpenStack" is still listed as the author/maintainer of this package. "os-net-config" was retired early last year along with the rest of the TripleO project within OpenStack's governance [2]. It appears that development has continued outside of OpenStack with the project being forked [3]. There have been releases that were uploaded to PyPi since. A human maintainer was added to PyPi this week. There may be some rationale to continue to maintain this code. Since the project was officially retired from OpenStack, we need to ensure that any renewed activity is properly communicated; and the author/maintainers are properly attributed. For one, "OpenStack" can't be the Author/Maintainer of a project that's not officially under OpenStack Governance. There are references to the OpenStack Documentation Website, TC Badges and IRC/bug tracker links that may now be obsolete and must be removed. This could be confusing to past, current and future users of the project, not to mention the security implications and responsibility attribution on code that's used in systems worldwide. Can the current maintainers please engage with us to make the necessary changes? You can do so here, or chat on #openstack-tc on OFTC. Thanks, Goutham Pacha Ravi [1] https://pypi.org/project/os-net-config [2] https://review.opendev.org/c/openstack/governance/+/905145 [3] https://github.com/os-net-config/os-net-config

4 4

[neutron][openvswitch] NAT + AFS = Sadness
by Jonathan Proulx 17 Nov '25

17 Nov '25

HI All, CERN may be the only other people doing anything with AFS hopefully this catches someone's eye who will just know.... The AFS filesystem use a rather "unique" connection oriented UDP protocol https://docs.kernel.org/networking/rxrpc.html This is where all our user home directories live so at's a key requirement for us. In my production cloud (mitaka sadly) we use direclty routable fixed IPs by default and all is well. In test (epoxy) we want to move away from the public v4 default IPs and lean more on floating ips for public addressing. Testing this I found impossibly poor performance for AFS behind NAT (with or without floating IP in front) on both Mitaka and Epoxy (both using openvswitch and DVR). This isn't a general NAT issue as I and others can use AFS from our homes behind comsumer NAT boxes of various sorts, and stand alone VMs out side OpenStack behind iptables based NAT are also fine. tcpdumping the connection on the fileserver sees strings of ICMP unreachable messages from the OpenStack router address (or floating ip if attahced) mid conversation. My guess is that the NAT is not maintianing stable enough port mapping becuase of the generally true assumption that UDP is stateless and will work itself out. I'm not really deeply familiar with using openvswitch for NAT as seems to be happening. Is there something I can look for in the flow rules to see what's going on? Can I tune anything to make the mappings more stable (assuming that's the issue) or am I just going to need to keep the old architecture that works? Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

2 4

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-19)
by Goutham Pacha Ravi 17 Nov '25

17 Nov '25

Hello Stackers, We're nineteen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Last week was Milestone 1 of this release, which project teams used to track features and bug fixes; it also served as an opportunity to ship some incremental releases across various deliverables [2]. Following up from the Project Teams Gathering, the OpenStack Technical Committee is working on Special Interest Groups within the community. The goal is to identify SIGs that need help, combine efforts, and clean up cruft in our documentation. Historically, SIGs were under the combined purview of the OpenStack Technical Committee and the OpenStack User Committee. Since these governance bodies merged in 2020, it's time to achieve more while doing less. We are combining the "governance-sigs" repository with the "governance" repository, and then auditing the SIGs and updating other outdated governance information. I encourage you to view the current SIGs [3], and if you're interested in joining an active SIG, or reforming an inactive one, please do let us know via this mailing list, or by joining the #openstack-tc IRC channel on OFTC. === Weekly Meeting === The TC met over IRC on November 11th, 2025 [4]. We followed up on action items from the recent Project Team Gathering (PTG). We added tasks to our backlog to analyze the 2025 User Survey results, and to rework the FIPS Compliance goal around testing and objectives. A new action item was assigned to clarify and document the TC's policy regarding AI/LLM contributions through the Project Team Guide. We discussed the retired project, os-net-config. The project's maintainers have removed OpenStack CI and fixed the author metadata on PyPI, as was flagged in a discussion on this mailing list [5]. There was some concern that this was problematic as it could mislead users into installing non-OpenStack-governed code without knowledge that this governance change had occurred. The consensus was that while it might be too much effort to force a PyPI name change, the TC would draft a formal resolution to retroactively acknowledge the project's handover and focus efforts on locking down PyPI access for any remaining OpenStack projects to prevent similar uncoordinated takeovers. I'll keep you posted regarding this. Wrapping up, OpenDev administrators announced the successful completion of Debian Trixie mirroring in the CI, making a DevStack job available for project teams to test with. The next meeting of the OpenStack TC is today, November 18th, 2025 at 0800 UTC. It will be hosted via IRC on OFTC's #openstack-tc channel. Please find the meeting's agenda and other details in the meeting's wiki page [6]. Please note that the TC has begun hosting a monthly meeting at this new time so we can encourage participation from folks in APAC countries. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Merge governance-sigs repository into governance | https://review.opendev.org/c/openstack/governance/+/966644 ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 - [resolution] Retire governance-sigs repository | https://review.opendev.org/c/openstack/governance/+/966645 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 === Upcoming Events === - 2025-12-09: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-12-04: 2026.1 release deadline for "cycle-trailing" projects - 2026-01-08: 2026.1 Milestone 2 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] Milestone 1 releases: https://review.opendev.org/q/topic:%22gazpacho-milestone-1%22 [3] OpenStack Special Interest Groups: https://governance.openstack.org/tc/reference/sigs/ [4] TC Meeting IRC Log, Nov 11th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-11-17.01.html [5] os-net-config: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] TC Meeting Agenda, Nov 18 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0