- openstack-discuss - lists.openstack.org

[all] Another day another CI failure
by Brian Haley 05 Mar '26

05 Mar '26

Hi, Started seeing tox failures in pep8/docs/unit and some other jobs: AttributeError: 'Parsed' object has no attribute 'config_format' Melanie Witt provided some info at [0][1], I opened a bug [2] as it seems like it was caused by a recent commit. I would hold rechecks until someone confirms it's fixed. -Brian [0] https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-pep8&ski… [1] https://paste.opendev.org/show/bS87fFXvqOKODTRMllg4/ [2] https://github.com/tox-dev/tox/issues/3866

1 0

[neutron] multicast and allowed address pairs
by Bence Romsics 05 Mar '26

05 Mar '26

Hi Neutrinos, We have a user who discovered that two neutron backends behave differently when it comes to handling multicast traffic. This user runs servers that need multicast for VRRP coordination (the point is multicast, not VRRP). They discovered that with the (no longer upstream supported) OpenDaylight backend, they need to let the multicast traffic through with an allowed address pair. On the other hand, the ml2/ovs backend (here always assuming the ovs firewall driver) allows the multicast traffic by default. If you add the same allowed address pair (for example: {'mac_address': '01:00:5e:00:00:64', 'ip_address': '224.0.0.100'}) as with OpenDaylight, it actually breaks multicast traffic. The traffic breaks even on other servers, affected by the same set of flows installed by ovs-agent. My question is: which backend behaves correctly? And do we need to change anything upstream? Since I found the following upstream history... https://opendev.org/openstack/neutron/src/branch/master/doc/source/admin/co… https://bugs.launchpad.net/neutron/+bug/1889631 ... I believe that ml2/ovs (with the ovs fw driver) behaves correctly when it lets the multicast traffic through by default. However I believe it is a bug that the traffic breaks when the user adds the allowed address pair. But I think it would be pretty pointless to start fixing the traffic itself since we would need to make changes for no effect. Rather we could reject allowed address pairs with multicast IPs/MAC addresses, because that would call the attention of the user that multicast traffic is already handled at a different place (that is the default behavior of the fw driver). I also believe that the OpenDaylight driver is buggy when it does not let the multicast traffic through just like ml2/ovs does. However this is not an upstream problem anymore, since networking-odl is long deprecated. Do you agree in the judgement where the bugs are in this case? The possible upstream change: Do you think we should start rejecting allowed address pairs with multicast IPs/MAC addresses? Plus I guess a doc update for allowed address pairs api-ref is due... If needed, I'm happy to bring this to the drivers meeting. It's 100% that I could attend next Friday (6th of March) and 80% for this Friday (27th of February). Thanks, Bence

3 2

Re: Update on RDO: A Shift to Containers
by Jose Castro Leon 05 Mar '26

05 Mar '26

We are also heavily affected by this change, as all our deployments at CERN rely on it. Moreover, we are early adopters of RDO and now that we are getting into Epoxy release, it just slips away. The deployment model is not something you can easily change. Does it also mean that our el10 users may never have client libraries packaged to use our setups? And following Massimo remark, will the repo be maintained while it's still in supported status in OpenStack? If not, are you implying that we also need to repackage future security updates? Thanks, Jose CERN Cloud Team ________________________________ From: Massimo Sgaravatto <massimo.sgaravatto(a)gmail.com> Sent: Thursday, March 5, 2026 1:40 PM To: Amy Marrich <amy(a)demarco.com> Cc: RDO Developmen List <dev(a)lists.rdoproject.org>; openstack-discuss <openstack-discuss(a)lists.openstack.org>; users(a)lists.rdoproject.org <users(a)lists.rdoproject.org>; Mike Burns <mburns(a)redhat.com> Subject: Re: Update on RDO: A Shift to Containers A non-negligible impact for our deployment :-( So, as far as I understand, no rpms will be released for the F and G releases, correct? Will you keep releasing updated RPMs for the Epoxy release, while it is in the maintained status, or the repo https://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-epoxy/ will not be updated anymore ? Thanks, Massimo On Wed, Mar 4, 2026 at 4:19 PM Amy Marrich <amy(a)demarco.com<mailto:amy@demarco.com>> wrote: Dear RDO Community/Stakeholders, This email provides an important update regarding the RDO project and its future direction which marks a significant change in how RDO content will be delivered. End of RDO RPM Builds Historically, RDO provided RPM-based rebuilds of upstream OpenStack packages. Due to insufficient contributors, the continuous RDO rpm builds that were released through the CentOS Cloud SIG have been officially discontinued as of the Epoxy release. Introducing the New RDO: Container Focus The future of RDO will be focused entirely on containers. This is a pivot from our traditional RPM delivery, as RDO did not previously focus on containers. RDO will be transitioning to Source-to-Image (S2I) builds for service containers. This work will be starting shortly within the <http://github.com/openstack-k8s-operators> github.com/openstack-k8s-operators<http://github.com/openstack-k8s-operators> organization, and these new container builds will essentially be the "new RDO". Timeline and Usage: * This transition work has not yet begun. The timeline is not committed, but the work is currently expected to be available for the Hibiscus release in late 2026. The final delivery location of those images is still to be determined. * These containers are primarily intended to be consumed via the operators provided in the openstack-k8s-operators GitHub organization. * While nothing explicitly prevents these containers from being used elsewhere, this is not currently part of the plan. Community involvement and feedback for broader usage are welcome including within OKD and the okderators. * Please note that the operators in this organization are currently only developed and tested on Red Hat OpenShift Container Platform. Thank you for your understanding and continued support as we make this important shift. We look forward to engaging with the community on this new path forward. Sincerely, Amy

1 0

[cinder] festival of reviews friday 2026-03-06
by Brian Rosmaita 05 Mar '26

05 Mar '26

Hello Argonauts, It's the first week of March, which means that the twice monthly Cinder Festival of Reviews will be held at the end of this week on Friday 6 March. who: Everyone! what: The Cinder Festival of Reviews when: Friday 6 March 2026 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 See you there!

1 0

[puppet][tc] Future of the project
by Takashi Kajinami 05 Mar '26

05 Mar '26

I had similar discussions earlier in #puppet-openstack several times, but I think it's time to start more formal discussions. As some of you may know, Puppet OpenStack project has been facing several challenges for a few years due to the changes made in the external but related communities, and very honestly speaking, the project is at risk. IMO we have two major challenges now. - RDO officially announced that they discontinue RPM builds and focus on new container-base delivery, based on source-to-build. https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/threa… Because the primary (and only) architecture we currently support is installation from packages, this means CentOS Stream may no longer be in our support scope. CentOS Stream + RDO has been the primary (and only voting) test architecture because it provides the trunk packages which allow us to test the latest code in development. We could technically switch our primary test architecture to the other platforms like Ubuntu or Debian but this means we can't release our modules in coordinated release timings (because we can implement and test the changes for a new version only after the version is released by these distributions) As we've seen some drastic changes triggered by some initiatives (like eventlet removal) and expect more coming soon, this "lagging-behind" development models can cause several problems like [1]. [1] https://review.opendev.org/c/openstack/puppet-neutron/+/978000 - The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676 So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days. I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle. Please reply to this in thread or reach me directly (in email or irc) if you are interested in further discussions. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 4

[kolla-ansible][flamingo][horizon] Network creation problem
by Franck VEDEL (UGA) 05 Mar '26

05 Mar '26

Hello everyone, I have a production OpenStack cluster for ESM students running Epoxy, deployed with Kolla-Ansible, and everything is working perfectly. I’m very satisfied with this setup. To prepare for upgrades, I set up a new test cluster in parallel using Kolla-Ansible, but this time with Flamingo. Everything seemed fine until I tried to create a network and its subnet in Horizon. The network is created, but no availability zone is associated with it. As a result, I cannot launch instances on this network. Could this be a change in the new OpenStack installation process that I missed? Or is this a bug? This is the first time I’ve encountered this issue. Is there a parameter that needs to be added in the Horizon override file (_9999-custom-settings.py) to handle this? Thanks in advance for any guidance. Franck VEDEL

1 0

Update on RDO: A Shift to Containers
by Amy Marrich 05 Mar '26

05 Mar '26

*Dear RDO Community/Stakeholders,This email provides an important update regarding the RDO project and its future direction which marks a significant change in how RDO content will be delivered.End of RDO RPM BuildsHistorically, RDO provided RPM-based rebuilds of upstream OpenStack packages. Due to insufficient contributors, the continuous RDO rpm builds that were released through the CentOS Cloud SIG have been officially discontinued as of the Epoxy release.Introducing the New RDO: Container FocusThe future of RDO will be focused entirely on containers. This is a pivot from our traditional RPM delivery, as RDO did not previously focus on containers.RDO will be transitioning to Source-to-Image (S2I) builds for service containers. This work will be starting shortly within the github.com/openstack-k8s-operators <http://github.com/openstack-k8s-operators> organization, and these new container builds will essentially be the "new RDO".Timeline and Usage: - This transition work has not yet begun. The timeline is not committed, but the work is currently expected to be available for the Hibiscus release in late 2026. The final delivery location of those images is still to be determined.- These containers are primarily intended to be consumed via the operators provided in the openstack-k8s-operators GitHub organization.- While nothing explicitly prevents these containers from being used elsewhere, this is not currently part of the plan. Community involvement and feedback for broader usage are welcome including within OKD and the okderators.- Please note that the operators in this organization are currently only developed and tested on Red Hat OpenShift Container Platform.Thank you for your understanding and continued support as we make this important shift. We look forward to engaging with the community on this new path forward.Sincerely,* Amy

2 1

testresources broken with latest fixtures
by Thomas Goirand 05 Mar '26

05 Mar '26

Hi, In its last version of fixtures, the tests folder has been move one directory up. Trying to rebuild testresources, it fails with: ERROR: unittest.loader._FailedTest.testresources.tests.test_test_resource ---------------------------------------------------------------------- ImportError: Failed to import test module: testresources.tests.test_test_resource Traceback (most recent call last): File "/usr/lib/python3.13/unittest/loader.py", line 396, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib/python3.13/unittest/loader.py", line 339, in _get_module_from_name __import__(name) ~~~~~~~~~~^^^^^^ File "/build/testresources-nCTnwj/testresources-2.0.2/testresources/tests/test_test_resource.py", line 18, in <module> from fixtures.tests.helpers import LoggingFixture ModuleNotFoundError: No module named 'fixtures.tests' This isn't seen downstream, as it's still possible to run latest versions of both fixtures and testresources, only testresources unit testing is broken with lastest fixtures, but I don't think it creates any issue for the users of these 2 libs. However, on the distro level, I'm not sure how to fix this... :/ Cheers, Thomas Goirand (zigo)

1 0

[requirements][horizon] Requirements freeze exception for XStatic-Font-Awesome
by Tatiana Ovchinnikova 04 Mar '26

04 Mar '26

Hello, I would like to request a requirements freeze exception to unpin XStatic-Font-Awesome and bump it from 4.7.0.0 to 6.2.1.2 [1]. This version doesn't use pkg_resources in build. From Horizon side we have worked around the required changes to use newer versions of the font [2], and after the requirements upgrade to 6.2 the hack can be safely removed. With kind regards, Tatiana [1] 977626: Bump XStatic-Font-Awesome to 6.2.1.2 and unpin it | https://review.opendev.org/c/openstack/requirements/+/977626 [2] 977249: A hack to make Horizon work with Font Awesome 6.2 | https://review.opendev.org/c/openstack/horizon/+/977249

2 1

[requirements][horizon] Requirements freeze exception for selenium
by Tatiana Ovchinnikova 04 Mar '26

04 Mar '26

Hello, I would like to request a requirements freeze exception to unpin Selenium and bump it from 3.141.0 to 4.41.0 [1]. Selenium 3.141.0 no longer works with modern urllib3. It needs to be updated to ensure compatibility with other libraries like urllib3. All required work has been done from Horizon side [2]. As a temporary workaround local upper-constraints.txt was created [3], and the follow up patch to remove it and roll back to global requirements is prepared [4]. With kind regards, Tatiana [1] 978157: Unpin selenium and use latest | https://review.opendev.org/c/openstack/requirements/+/978157 [2] 978177: Upgrade selenium to 4.41.0 | https://review.opendev.org/c/openstack/horizon/+/978177 [3] 978078: Create and use local upper-constraints to avoid Selenium failing | https://review.opendev.org/c/openstack/horizon/+/978078 [4] 978896: Remove local upper-constraints and go back to global one | https://review.opendev.org/c/openstack/horizon/+/978896

2 1