- openstack-discuss - lists.openstack.org

Nova
by engineer2024 28 Jan '25

28 Jan '25

Does nova support flavors where vcpus of a single flavor can be in mixed modes where some of them are pinned and the rest dedicated ? Say, a flavor has 5 vcpus, I want 2 of them to be of dedicated type and the remaining 3 vcpus to be shared

2 2

[neutron][upgrades] IPv6 Prefix Delegation 'dibbler' driver removal
by Brian Haley 28 Jan '25

28 Jan '25

Hi again Stackers, In 2023, during the Bobcat cycle, the Neutron team changed the IPv6 Prefix Delegation (IPv6 PD) 'dibbler' driver to be an experimental feature [0]. The reason was due to it (dibbler) becoming unmaintained/retired upstream, as well as the low level of testing support we had in Neutron for the feature. So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the driver from the tree [1]. The framework to support IPv6 PD is *not* being removed, but as this is the only in-tree driver the functionality will no longer be available to end-users. We plan on doing this in the current Epoxy cycle. We realize that there may be deployments using IPv6 PD, although we have not to my knowledge ever received a bug against it, so we think any usage is very small. If there is desire to add an in-tree driver back to the code base, there is an open OVN-related bug for that at [2], we have just not had the interest from downstream customers to warrant the investment in this area. Thanks for reading, -Brian, Neutron PTL [0] https://review.opendev.org/c/openstack/neutron/+/879030 [1] https://review.opendev.org/c/openstack/neutron/+/934283 [2] https://bugs.launchpad.net/neutron/+bug/1895972

1 0

[Octavia][magnum] change timeout value
by Satish Patel 28 Jan '25

28 Jan '25

Folks, I am running magnum-cluster-api (mcapi) with openstack to spin up k8s but now I want to change octavia LB timeout. Is there a way to tell magnum to change the timeout value of LB? loadbalancer.openstack.org/timeout-client-data: "120000" loadbalancer.openstack.org/timeout-member-data: "120000"

1 0

[Nova] Nova-compute service flapping on Antelope
by Jakub Darmach 28 Jan '25

28 Jan '25

Hello, Recently I encountered an interesting issue - nova-compute service started to temporarily lose Rabbit connectivity to regain it after a few seconds on Antelope. The issue was replicated on the test environment, without specific steps to replicate though - it just starts to happen after some time. I pasted a log example in the bug I opened [1]. First we can see rabbit logging closing AMQP connection, followed by nova-compute reporting rabbit server being unreachable, with next message being successful reconnection. Restarting nova-compute services helps temporarily, the issue starts to manifest after a few days. Initially disconnects once every few hours, each time in shorter intervals, to the point it happens every minute or so. Did anyone encounter something similar? [1] https://bugs.launchpad.net/nova/+bug/2092297 Pozdrawiam / Best regards, *Jakub Darmach*

3 2

[administrivia] Bounce processing disabled for now
by Jeremy Stanley 28 Jan '25

28 Jan '25

Due to repeated challenges with random messages being rejected by subscribers' mail providers (from DMARC invalidations, lines too long to be forwarded, content misidentified as spam, et cetera), the time required for list administrators to manage the resulting extra work is greater than the benefit we get from Mailman being able to figure out when subscriber addresses become defunct. As such, I've disabled the "bounce processing" feature for the time being, until we can work out solutions to make it less of a burden on our list admins and less confusing/failure prone for the list subscribers. If we do decide to give it another try at some point in the future, after some of the current challenges with it get ironed out, I'll let the list know. -- Jeremy Stanley

1 0

openstack-discuss-owner mailbox
by Albert Braden 28 Jan '25

28 Jan '25

Is anyone manning the openstack-discuss-owner mailbox? I've been writing to that address about the recent glitch that deleted my list subscription and account (and according to the error message, hundreds of others), but I'm not getting a response.

2 3

[publiccloud-sig] Public Cloud SIG Meeting this week
by Felix Kronlage-Dammers 28 Jan '25

28 Jan '25

Hi everyone, This upcoming Wednesday (January 29th) the next meeting of the publiccloud-sig is going to happen or at least would happen: However I’ll not be around tomorrow to facilitate and I did not get any feedback from anyone else on it. Usually we would be meeting at 0800 UTC here: https://meetpad.opendev.org/publiccloud-sig - so give it a shot ;) See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG felix -- Felix Kronlage-Dammers Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[nova] Performance Issues with OpenStack Server List on os-compute-api-version 2.96
by 黒羽正徳 [Kuroha Masanori] 28 Jan '25

28 Jan '25

Hello, We have recently encountered a situation where the response time for the openstack server list command is significantly slower when specifying os-compute-api-version 2.96 for certain projects. In comparison with version 2.95, some projects experience a response time that is 2-3 times longer, while other projects show little to no difference. We understand that in version 2.96, there was a change to obtain the availability zone from the request_spec [1]. However, upon checking the instance records in request_spec for the projects, we have not identified any differences that would account for this slow response behavior. Additionally, we have observed that when certain ERROR VM is present, the response time for the server list can become considerably slower for specific projects. In one case, we resolved the slow response issue by deleting instances that did not have corresponding fault records in the database. However, the exact reason why this action resolved the issue remains unclear. If anyone has more detailed information or potential solutions regarding these issues, or if you have encountered similar situations, we would greatly appreciate your insights. [1] https://git.linecorp.com/Flava-IaaS/nova/commit/c98c8d84eec6e65f1b67ae1ab82… Best regards, Masanori Kuroha

1 1

[largescale-sig] Next meeting: January 15, 9utc
by Thierry Carrez 27 Jan '25

27 Jan '25

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20250115T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

3 3

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-9)
by Goutham Pacha Ravi 27 Jan '25

27 Jan '25

Hello Stackers, We're 9 weeks away from OpenStack's 2025.1 coordinated "Epoxy" release [1]. These weeks leading up to feature freeze (R-5/Feb 24-28) will be about "getting things done" for project teams. As Slawek Kaplonski (slaweq) wrote to you [2], we'll be kicking off combined elections for Project Team Leads for the 2025.2 "Flamingo" release cycle and five seats on the OpenStack Technical Committee next week. In light of this, please confirm your eligibility to vote in these elections by navigating to the CIVS website and entering your Gerrit email address: https://civs1.civs.us/cgi-bin/opt_in.pl In each of the past three elections, we've had roughly a fifth of eligible voters cast their votes. It would make a great difference to our community if we could improve this statistic with your cooperation! In the past week, the OpenStack Technical Committee approved a resolution to welcome the "Freezer" (Disaster-Recovery-as-a-Service) project back into the fold of "active" projects [3]. I'd like to extend a shout-out to Dmitriy Rabotyagov (noonedeadpunk) and Álvaro Soto (khyr0n) for their work to revive the project team. The team is looking to pursue the release of several project deliverables during this release. === Weekly Meeting === The TC weekly IRC meeting on 2025-01-21 [4] was well attended. We were in "getting things done" mode too, as much of the meeting followed up on action items from past meetings. We discussed getting more active review participation for changes to the "openstackdocstheme" repository by working with the Oslo team. We also deliberated on election nomination windows. We are in favor of early nominations from folks who are unable to self-nominate due to holidays or other personal reasons to be away from their computers during the nomination window. However, there were concerns expressed that the election officials may be burdened by the work necessary to shepherd such nominations. Early nominations would fail several CI checks, require re-checks, and potentially create some confusion. We'll attempt to watch this closely for the next election cycle and recalibrate. Our goal is to avoid leaderless projects due to holiday cycles during elections. The TC also discussed the next steps for the newly active Freezer project to release artifacts during the current release cycle. The next meeting of the OpenStack TC is today, 2025-01-28, at 1800 UTC in the #openstack-tc IRC channel on OFTC. Please find the meeting's agenda on the meeting wiki [5]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Retire Freezer DR | https://review.opendev.org/c/openstack/governance/+/938183 - Remove Freezer from inactive state | https://review.opendev.org/c/openstack/governance/+/938938 ==== Open for Review ==== - Retire qdrouterd role | https://review.opendev.org/c/openstack/governance/+/938193 - Reset the DPL model for Oslo project | https://review.opendev.org/c/openstack/governance/+/939485 - Reset the DPL model for Release project | https://review.opendev.org/c/openstack/governance/+/939486 - Add devstack-plugin-prometheus repo to Quality Assurance repos | https://review.opendev.org/c/openstack/governance/+/939953 - Reset the DPL model for Watcher project | https://review.opendev.org/c/openstack/governance/+/939488 - Add Watcher project update liaison | https://review.opendev.org/c/openstack/governance/+/940168 - Adopt DPL model for Watcher 2025.2 | https://review.opendev.org/c/openstack/governance/+/940167 - Define 2025 upstream investment opportunities | https://review.opendev.org/c/openstack/governance/+/939507 - Add resolution for late Freezer release | https://review.opendev.org/c/openstack/governance/+/939792 - Deprecate ironic-lib | https://review.opendev.org/c/openstack/governance/+/939278 - Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 === Upcoming Events === - 2025-01-28: OpenInfra Board Monthly Meeting: https://board.openinfra.org/ - 2025-02-01: FOSDEM 2025 (https://fosdem.org/2025/) OpenStack's 15th Birthday Celebration - 2025-02-05: Nominations open for 2025.2 TC/PTL Elections: https://governance.openstack.org/election/ - 2025-02-28: 2025.1 ("Epoxy") Feature Freeze and release milestone 3 [1] - 2025-03-06: SCALE 2025 + OpenInfra Days NA (https://www.socallinuxexpo.org/scale/22x) Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] 2025.2 Election Kickoff: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] Remove Freezer from inactive state: https://review.opendev.org/c/openstack/governance/+/938938 [4] TC Meeting IRC Log 2025-01-21: https://meetings.opendev.org/meetings/tc/2025/tc.2025-01-21-18.00.log.html [5] TC Meeting Agenda, 2025-01-28: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[mistral] meetings during next PTG
by Arnaud Morin 27 Jan '25

27 Jan '25

Hey all, Next PTG will take place between April 7 to 10. Is there anyone willing to talk about mistral developement during this PTG? So far, mistral has not evolved that much, but maybe someone is having ideas about it? Also, there is this eventlet-removal topic that could be discussed. Let me know, Cheers, Arnaud.

1 0

[neutron] Bug Deputy Report Jan 20 - Jan 26
by Yatin Karel 27 Jan '25

27 Jan '25

Hi Neutrinos, Below is the bug deputy report for last week:- High ------ - https://bugs.launchpad.net/neutron/+bug/2095807 - OVN loadbalancer via FIP does not work for DVR + VLAN networks Unassigned OVN octavia provider, Asked Fernando to have a look as could be known one - https://bugs.launchpad.net/neutron/+bug/2095598 - test_async_process_respawns functional test failing in fips functional job Unassigned We thought it would get fixed with https://review.opendev.org/c/openstack/neutron/+/939627 but it's not, so have to be checked again - https://bugs.launchpad.net/neutron/+bug/2095595 - The neutron-dhcp-agent resync throttling mechanism doesn't work Assigned to Anton Kurbatov - https://bugs.launchpad.net/neutron/+bug/2095590 - [OVN] Neutron API stops refreshing the hash ring node Assigned to Rodolfo - https://bugs.launchpad.net/neutron/+bug/2095566 - [OVN] Router creation timeouts randomly Unassigned Rodolfo mentioned he has some fixes in flight to cover ovn wsgi related issue, so to confirm if this is also covered. Medium ---------- - https://bugs.launchpad.net/neutron/+bug/2095576 - [OVS] False ERROR log message every time when creating VM Unassigned - https://bugs.launchpad.net/neutron/+bug/2095322 - ADMIN_OR_NET_OWNER_{MEMBER|READER} rules don't work for subnets Unassigned Incomplete --------------- - https://bugs.launchpad.net/neutron/+bug/2096704 - [RFE] Allow rebalancing of OVN LRPs Asked for more context -- Thanks and Regards Yatin Karel

1 0

[all][elections][ptl][tc] Combined PTL/TC 2025.2 cycle Election Season
by Sławek Kapłoński 27 Jan '25

27 Jan '25

Hi, Election details: https://governance.openstack.org/election/ The nomination period officially begins Feb 05, 2025 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in these governance documents[1][2][3]. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. Similarly, there will only be a TC poll if there are more than 5 candidates stepping forward the available TC positions. All members of the community are encouraged to confirm their email address as described at: https://governance.openstack.org/election/#electorate There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you wish to discuss in private please email any of the election officials[4] so that we may address your concerns. Thank you, [1] https://governance.openstack.org/tc/reference/charter.html [2] https://governance.openstack.org/tc/reference/role-of-the-tc.html [3] https://docs.openstack.org/project-team-guide/ptl.html [4] https://governance.openstack.org/election/#election-officials -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[openstack-helm] Use Loci images by default
by Vladimir Kozhukalov 26 Jan '25

26 Jan '25

Hi, This is to announce multiple things: 1) OpenStack/Loci (a project for building OpenStack images) is currently equipped with periodic jobs that are run nightly. These jobs build images for 3 most recent OpenStack releases: - 2023.2 Bobcat - 2024.1 Caracal - 2024.2 Dalmatian Images are published to these two destinations: - docker.io/loci/* (which is known for its strict request rate limits) - quay.io/airshipit/* (which is much more tolerant to the number of requests) Images are tested before publishing with two basic deployment configurations: - compute-kit (Deploy minimal set of OpenStack components to run VMs) - cinder (Deploy Cinder with Ceph backend) 2) By default we are going to use Loci images published to the Quay registry [1]. All test jobs will be run with these images and this is also a recommendation for users to consume images from quay to mitigate possible rate limit issues. 3) OpenStack/OpenStack-Helm-Images project will build only non-OpenStack images. Primarily the motivation is to deduplicate the code base. Consequently, OpenStack images published nightly to docker.io/openstackhelm/* will not be updated after 2024.2. [1] https://review.opendev.org/c/openstack/openstack-helm/+/939426 -- Best regards, Kozhukalov Vladimir

2 2

Guidance Required for OVN-BGP-Agent Configuration with EVPN Mode
by AkashMadan Talebailkar 26 Jan '25

26 Jan '25

Dear Community, I hope this email finds you well. I came across this insightful discussion on the OpenStack forum regarding the OVN-BGP-Agent Discussio<https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030080.…>n. We are doing research on openstack capability and would greatly appreciate your guidance. We are utilizing the OVN mechanism driver along with the OVN-BGP-Agent<https://github.com/openstack/ovn-bgp-agent/tree/master> in EVPN mode. Our objective is to establish BGP-EVPN between our leaf switch and the OpenStack controller. The OVN-BGP-Agent should advertise the IP and MAC addresses of VMs to its BGP peers. Please find attached the following details for your reference: bgp-agent.conf Agent configuration OVN_DB configuration Result We installed the OVN-BGP-Agent and FRR on the controller. Below are the steps we followed: Network Setup: Created a tenant network (NET) with a subnet of 121.168.0.0/24. Created a provider network (EXNET) with a subnet of 192.27.5.0/24. Router Configuration: Set up a router (newrouter) with an external network (EXNET) and unchecked SNAT. Added the NET interface to the router. OVN Database Configuration: Configured the OVN Northbound DB (detailed in the attachment). VM Creation: Deployed a VM in NET with the VM's IP 121.168.0.202 PFA for the agent configuration and FRR configuration done once agent VM has been created. Despite following the steps above, the VM IP is not visible in FRR, PFA for the result. Consequently, we are unable to advertise its route via BGP-EVPN. We kindly request your guidance to identify any potential misconfigurations or missing steps. Thank you for your time and support. Best regards, Akash Talebailkar Palc Networks akashmadan.t(a)palcnetworks.com +91 9035376555

2 1

[manila][cephfs][kollla-ansible]cannot create access rule on share
by Nguyễn Hữu Khôi 25 Jan '25

25 Jan '25

Hello. I setup manila with cephfs driver-CephFS NFS shares and I use NFS-Ganesha based “ceph nfs” service. This is my configuration: [DEFAULT] debug = true enabled_share_protocols = NFS,CIFS,CEPHFS [cephfsnfs1] driver_handles_share_servers = False share_backend_name = CEPHFSNFS1 share_driver = manila.share.drivers.cephfs.driver.CephFSDriver cephfs_protocol_helper_type = NFS cephfs_conf_path = /etc/ceph/ceph.conf cephfs_auth_id = manila cephfs_cluster_name = az1 cephfs_filesystem_name = cephfs I can create a share but cannot set access rule for it and I encountered this error in manila-share.log: 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.10/site-packages/manila/share/drivers/ganesha/manager.py", line 472, in add_export 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server self._dbus_send_ganesha("AddExport", "string:" + path, 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.10/site-packages/manila/share/drivers/ganesha/manager.py", line 410, in _dbus_send_ganesha 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server self.execute("dbus-send", "--print-reply", "--system", 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.10/site-packages/manila/share/drivers/ganesha/manager.py", line 240, in _execute 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server raise exception.GaneshaCommandFailure( 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server manila.exception.GaneshaCommandFailure: Ganesha management command failed. 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Command: sudo manila-rootwrap /etc/manila/rootwrap.conf dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.AddExport string:/etc/ganesha/export.d/share-5d49f7c6-27a0-43c3-931d-56486b8f3d51.conf string:EXPORT(Export_Id=106) 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Exit code: 96 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Stdout: '' 2025-01-25 22:00:11.895 774 ERROR oslo_messaging.rpc.server Stderr: '/var/lib/kolla/venv/bin/manila-rootwrap: Executable not found: dbus-send (filter match = dbus-addexport)\n' One more thing, when I run openstack share export location list myshare I see lab-control01:/volumes/_nogroup/5d49f7c6-27a0-43c3-931d-56486b8f3d51/fb094ad8-9200-4c93-b800-304178f51136 lab-control01 is my openstack controller, is it right because nfs service is on ceph cluster. Thank you. Nguyen Huu Khoi

1 1

[all][PTLs][release] OpenStack 2025.2 Flamingo release schedule plan
by Elõd Illés 24 Jan '25

24 Jan '25

Hi everyone, Let me inform you that 2025.2 Flamingo release schedule plan can be reviewed: https://review.opendev.org/c/openstack/releases/+/939528 (or for better reading you can take a look at the generated preview for Patch Set 1 [1] but note that the link **only** works for Patch Set 1!) [1] https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/… Cheers, Előd Illés irc: elodilles @ #openstack-release

1 0

[kolla-ansible] Multipath unsuccesfull in nova
by Kamil Madac 24 Jan '25

24 Jan '25

Hello, I have a openstack deployed with kolla-ansible 2024.2. I'm trying to configure cinder and nova to use multipath when attaching volumes from the Hitachi SAN array. Without multipathing everything works good. When I enabled multipath in kolla-ansible (enable_multipathd: "yes"), deployment is without errors, volume can be created, but attachment of volume ends up with error in nova_compute container: ... 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] raise exc_type(*result[2]) 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] Command: multipath -C dm-0 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] Exit code: 1 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] Stdout: '' 2025-01-22 12:16:02.962 2 ERROR nova.virt.block_device [instance: 714bd6f8-49e5-406f-b608-b7aaded2e728] Stderr: '3601817.750747 | /etc/multipath.conf does not exist, blacklisting all devices.\n3601817.750753 | You can run "/sbin/mpathconf --enable" to create\n3601817.750754 | /etc/multipath.conf. See man mpathconf(8) for more details\n3601817.751393 | sdd: error 2 in pathinfo, discarding path\n3601817.751501 | sde: error 2 in pathinfo, discarding path\n3601817.751504 | 360060e8012b142005040b14200000ee2: removing empty pathgroup 0\n3601817.751505 | dm-0: no usable paths found\n' When I manually added /etc/multipath.conf to nova_compute container, the attachment passed without any issues. I do not want to build special image only because of that single config file. My question is, how to make kolla-ansible to copy/add /etc/multipath.conf file into nova_compute service? Is there any mechanism for that? Thanks. Kamil Madac

3 4

[nova][neutron][ops] disabling the heal instance info cache periodic
by Sean Mooney 23 Jan '25

23 Jan '25

hi folks o/ This is a short PSA and request for comments The nova and neutron teams have discussed the existence and importantly the default behavior of nova's "heal instance info cache periodic" on an off for the better part of the last 4+ years but we never had time to take any action on it until now. Context for those who are not aware of it, nova has an instance info cache which we use to cache networking information such as ip address related to ports associated with an instance. This was introduced in the Essex release when nova networks was being replaced with quantum/neutron. Its rater fitting but over due that in the Epoxy release we are now turning this off. for more context i have captured some of the important point in the release note of the proposed change https://review.opendev.org/c/openstack/nova/+/939476/2/releasenotes/notes/d… But ill provide a TL;DR here. By default, as of essex, [compute]heal_instance_info_cache_interval defaulted to 60. it has been possible to disable this by setting the value to <=0 (recommended to use -1 by convention). when the periodic is enabled, every nova compute agent loop over the instance on the current host, retrieves all there ports form neutron and fully rebuilds the cache(as of stein). on a small cloud (less then 50 computes) this has minimal impact on the performance of the neutron server, on moderate to large clouds this creates 10s of MB of constant db read load. This has several side-effects: - first it creates unnecessary load on the neutron api and neutron db/network backend in creasing latency and reducing overall performance. - second, it create unnecessary load on rabbitmq as each compute service need to do an RPC to update the info cache(every 60 seconds). - third both of the first two waste power doing extra work that is not needed. - finally as of Icehouse this periodic has been optional because we added the os-server-external-events api so that neutron can tell nova if there has been a change to refresh the cache as needed. With that in mind hte nova team is proposing that we disable this going forward, for this release i have not deprecated the periodic so operators can re-enable it if they find its required for any reason. in the 2026.1 release we will likely revisit this based on operator feedback/bug reports. In this weeks team meeting we agree to wait 2 more weeks to get feedback from OPS if they had any concerns with this change hence this email. If anyone knows of a reason why we should not proceed with this default change feel free to let us know via this email thread or the gerrit review https://review.opendev.org/c/openstack/nova/+/939476 regards sean

2 1

April 2025 PTG Dates & Team Signup Kickoff
by Kendall Nelson 23 Jan '25

23 Jan '25

Hello Everyone, I am pleased to announce the next OpenInfra PTG[1] will be taking place April 7-11, 2025! Registration will open soon! To sign up your team, you must complete the survey[2] by February 21st at 7:00 UTC. We NEED accurate contact information (email and and IRC nickname ideally) for the moderator of your team’s sessions. This is because the survey information will be used to organize the schedule signups which will be done via the PTGBot. If you are not on IRC, please get setup[3] on the OFTC network and join #openinfra-events. You are also encouraged to familiarize yourself with the PTGBot documentation[4] as well. If you have any questions, please reach out to ptg(a)openinfra.dev! Information about signing up for time slots will be sent to moderators after the team signup deadline. Continue to visit openinfra.org/ptg for updates. -Kendall (diablo_rojo) [1] PTG Site: https://openinfra.org/ptg/ [2] Team Survey: https://openinfrafoundation.formstack.com/forms/ptg_april_2025_survey [3] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [4] PTGBot README: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

1 0

[neutron] Drivers meeting canceled Friday, January 24th
by Brian Haley 23 Jan '25

23 Jan '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as there is no agenda. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[cinder] 2025.1 Midcycle reminder
by Jon Bernard 23 Jan '25

23 Jan '25

Hello all, this is a reminder that our midcycle meeting will take the place of next week's upstream meeting on 29 Jan. I've allocated 2 hours (as opposed to our usual 1) in case additional time is needed. The etherpad we'll be using is here [1]. See you all then! [1]: https://etherpad.opendev.org/p/cinder-epoxy-midcycles -- Jon

1 0

[Neutron][operators] LinuxBridge to OVN Outreach
by Daniel Failing 23 Jan '25

23 Jan '25

Dear operators of Neutron deployments using LinuxBridge, This mail is to target operators who plan to move away from neutron LinuxBridge as well. In our setup we are currently planing to move away from LinuxBridge and use OVN instead. Based on the last PTGs survey with quite a few deployments using LinuxBridge and it being marked experimental for some time, we feel there could be a common ground and pain points. We were wondering how many other operators have the same problems and want to share knowledge and if necessary consolidate code written for a potential migration. Knowing there are quite some different deployments, we most likely will not be able to find the golden solution that works for everyone, but we could strive for not making the same mistakes multiple times in different deployments. We are located in European timezones, if there are others interested in a zoom/jitsi call, please let me know your timezones/time preferences, so we find a good slot. Otherwise I can propose one of the following dates already: Friday, Jan 24st 2 or 3pm UTC Tuesday, Jan 28st 10am UTC Tuesday, Jan 28st 3:30pm UTC Wednesday, Jan 29st 10am UTC Friday, Jan 31st 2 or 3pm UTC Best, Daniel CERN Cloud Infrastructure [1] original thread: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

3 3

[openstack-ansible]:Wallaby to Xena Upgrade
by Rambo Rambo 23 Jan '25

23 Jan '25

Hi Team I am planning openstack-ansible wallaby to Xena upgrade. Distribution: openstack-ansible Release: Wallaby (current) ==> Xena (Planned) I was checking the release notes of Xena and could see that there is introduction of SSL in several services with nova for live migrations one of them. https://docs.openstack.org/releasenotes/openstack-ansible/xena.html As per the release notes: - Nova now defaults to to using the “QEMU-native TLS” feature for live migrations, rather than the deprecated SSH method. A pre-existing PKI (Public Key Infrastructure) setup is required. QEMU-native TLS requires all compute hosts to accept TCP connections on port 16514 and port range 49152 to 49261. More information can be found here: https://docs.openstack.org/nova/latest/admin/secure-live-migration-with-qem… Can you please confirm what steps are required to setup this PKI before doing the upgrade or it will be taken care by internal-pki using openstack-ansible upgrade method? Is there any option to skip this QEMU-native TLS for live-migrations and keep the orginal ssh based live-migrations? Regards

2 5

[all][oslo] revisiting the proposal to deprecate eventlet from oslo.service
by Mike Bayer 23 Jan '25

23 Jan '25

Hi - We've come to an impasse regarding our efforts to create a new backend selection system for oslo.service which will allow applications based on eventlet to have an incremental migration path where they can select for threads instead of eventlet [1] [2]. Briefly, the change organizes oslo.service into two different "backends", known as "eventlet" and "threaded". A calling application may choose to use either backend exclusively. Applications that use oslo.service right now are essentially using the "eventlet" backend. As these applications seek to migrate away from eventlet, they'd select the "threaded" backend and tune their applications to work under this new mode, where eventually the "eventlet" backend would be removed from oslo.service and ultimately from all of openstack entirely. All of that falls under things that have been agreed upon. The current impasse is among three options of how this "backend" system in oslo.service may be informed of which backend should be used: 1. being selected at runtime via CONF from the .cfg file , which is what was originally agreed upon 2. at start up time via environment variable 3. as a fixed setting in source code. Personally, as someone who has worked for decades on multiple switchable backend-oriented systems, I'm fully in the camp of choice 3, which is that switching the backend is just the beginning of a whole series of changes and tuning that a codebase would need in order to accommodate this backend change, and having the ability to "switch the backend back to eventlet" in CONF or runtime is simply not something anyone would want to do, unless a considerable amount of additional effort were made to support the codebase being reliable under both idioms. Which I would argue is a waste of effort since eventlet is going away. More concretely, if you took nova, which were using oslo.service with eventlet and decided to try the "threaded" backend, that's naturally going to have a lot of implications for other parts of the code. For example, if your code is setting eventlet monkey patching, that has to be turned off when this backend selection is made. If your code has other explicit use of eventlet, this also needs to be changed. Finally, threaded concurrency is naturally going to "feel" different than coroutine-based concurrency - context switches happen at different places and with different frequencies. Typically in a large codebase, the places that are prone to race conditions can shift; areas that had no races under coroutines now have threaded concurrency problems, areas that were sensitive to coroutine issues like being CPU bound are suddenly smooth with threading. The overall number of "working routines" can change, whereas eventlet can spin up 1000 coroutines like popcorn, under threads we now have to work with pools of threads typically a few dozen or so threads large. Overall, if I had my whole application passing under tempest under "threading", I would have had to make changes to get there, which may very well be mutually exclusive vs. test resiliency under eventlet. More generally, getting my application to run under threads represents a change in implementation that I expect to be permanent. If there are continued issues running under threaded mode, those are bugs that have to be fixed in any case. In the discussion at [1], Takashi Kajinami writes that a PTG discussion (for which I dont have any link or background) explicitly decided against the above idea: > In the initial design we considered that developer may make the decision to migrate from eventlet to the new mechanism, and didn't intend to provide any options to switch back to the original eventlet model. > However there was some strong push back during the previous PTG and people were concerned with having no mechanism to switch back to "previously worked well" eventlet model and to address the concern we agreed to introduce the option for operators to switch the backend. > If we don't allow users to configure the option then IMO we should not expose the option and we should use an internal flag instead (though that's basically what was disagreed with during the PTG, AFAIR) So first off, we have already realized that going with option 1. , use CONF, is not tenable, because the CONF collection is not typically in its final populated state when imports occur, and since the "backends" are an import time selection, there's a chicken/egg problem that cannot be resolved unless applications either highly modify the way in which their applications consume CONF vs. do their basic imports, or the way we are writing our backends in [1] needs to be modified so that imports can proceed using proxy objects which then change their loaded implementation when CONF is set up. Both of these options seem deeply complex and overarchitected in order to support the feature of "I want to change the backend in CONF" which I maintain is not going to be a real world use case. As a compromise, I suggested option 2. using an environment variable. This allows the backend selection to remain something that can be theoretically changed from the outside without modifying source code. However, current deployment practices suggest this is not really useful, as again per Takashi the way in which we deploy mod_wsgi does not allow environment variables to be local per virtual host; per [3] it looks like you need a hardcoded python script anyway that sets the env the way you want which makes it not too useful. As we were proceeding on option 2. we received some more pushback on the "env" idea from Arnaud Morin which I don't disagree with, and still more pushback and arguments leading in favor of 3, here from Jay Faulkner: > Using environment variables to set backends means that operators can change what backend is used. This is an easy thing for them to screw up and will end up creating a large amount of operator pain and bug churn. I am -1 in the strongest terms to the use of operator-adjustable values to enable/disable backends. The above was surprising considering that this was supposed to be a decision that had already been made at PTG, yet there still seems to be disagreement as though the decision were not actually made in any final way. So as I am tasked along with Daniel Bengtsson and Herve Beraud with getting [1] merged and moving onto building out the threaded backend, I would like to ask the group here to give me some background on the concerns raised at PTG and if we can all just here revisit the whole issue and hopefully decide that at least to start, let's get this merged without any CONF/env variable process (option 3); an application that's gone through the effort to transition to threads with the help of this backend selector should be assumed to be moving forward with that implementation, and if it has problems, that's just an ordinary bug like any other. thanks for reading! [1] https://review.opendev.org/c/openstack/oslo.service/+/935783 [2] https://review.opendev.org/c/openstack/oslo-specs/+/927503 [3] https://gist.github.com/GrahamDumpleton/b380652b768e81a7f60c

10 11

[kolla] Deprecating swift support
by Michał Nasiadka 23 Jan '25

23 Jan '25

Hello, Kolla and Kolla-Ansible is deprecating Swift deployment support, due to absence of active maintainers in the community for swift Kolla images and swift Kolla-Ansible role. If there are any volunteers to pick up that - please reach out either on #openstack-kolla or in the patch [1]. [1]: https://review.opendev.org/c/openstack/kolla-ansible/+/939968 Best regards, Michal

1 0

[watcher] Bug Triage Meeting - January 14, 2025, 12pm UTC
by Ronelle Landy 23 Jan '25

23 Jan '25

Hello All,We will be holding a IRC/Google Meet meeting on Tuesday, January 14, 2025 at 12pm UTC to start the triage process for the list of current Watcher bugs: <https://bugs.launchpad.net/watcher> <https://bugs.launchpad.net/watcher> - <https://bugs.launchpad.net/watcher>https://bugs.launchpad.net/watcher - https://bugs.launchpad.net/watcher-dashboard - https://bugs.launchpad.net/watcher-tempest-plugin Anyone interested in the Watcher project is invited to join the meeting on: - IRC channel #openstack-watcher - Google Meet link: meet.google.com/drk-bgbx-uyz Notes from the meeting will be captured on the IRC channel.Thank you

1 3

[Glance]Cancelling Today's Weekly Meeting
by Mridula Joshi 23 Jan '25

23 Jan '25

Hello, As PTL and I are not around today , hence skipping today's weekly meeting . If someone has anything to discuss, ping Abhishek or Cyril on the IRC channel . Thanks, Mridula Joshi

1 0

[security-sig][ops][neutron] OVN Security issue can impact OpenStack users
by Jay Faulkner 22 Jan '25

22 Jan '25

Hi all, A recent security issue with OVN recently came to light and was fixed in a recent release. Full details are here: https://www.openwall.com/lists/oss-security/2025/01/22/5 . OpenStack deployers running OVN are strongly recommended to upgrade to the new fixed version. No CVE number has been issued yet for this resolved vulnerability. As a note, this was originally reported to the VMT as a neutron bug, but after triage it was responsibly reported to OVN and has been held under embargo. Thank you to the folks who participated in this triage process, including the OVN community for fixing the issue. Please see https://bugs.launchpad.net/ossa/+bug/2088280 for full details on OpenStack handling of this security report. Thanks, Jay Faulkner OpenStack VMT

1 0

[openstack-ansible]: GPU passthrough
by Rambo Rambo 22 Jan '25

22 Jan '25

Hi Experts Release: Wallaby Distribution: Openstack-ansible I am working on enabling GPU computes through PCIpassthrough: I managed to test the GPU PCI passthrough with the direct configuration below. *GPU compute:* /etc/nova/nova.conf [pci] device_spec = { "vendor_id": "10de", "product_id": "25b6" } passthrough_whitelist = { "vendor_id": "10de", "product_id": "25b6" } alias = { "vendor_id": "10de", "product_id": "25b6", "device_type": "type-PCI", "name": "nvidia" } *Nova API container:* /etc/nova/nova.conf enabled_filters = AvailabilityZoneFilter,ComputeFilter,AggregateNumInstancesFilter,AggregateIoOpsFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,NUMATopologyFilter, *PciPassthroughFilter* [pci] alias = { "vendor_id": "10de", "product_id": "25b6", "device_type": "type-PF", "name": "nvidia" } Now I need to put the configuration through openstack-ansible. So I need support for the same. *compute:* I intend to use hostvar for the compute configuration: /etc/openstack_deploy/host_vars/compute-<>.yml Can someone please confirm the parameters I need to set in this file and how to implement it? device_spec = ? passthrough_whitelist = ? nova_pci_alias: - '{ "name": "nvidia", "product_id": "25b6", "vendor_id": "10de" }' =====> how can I add *device_type field* here as per the mail.yaml it only have name,product_id and vendor_id field? Run openstack-ansible os-nova-install.yml --tags nova-config --limit <compute name> *For nova_api configuration,* I intend to use below: Below parameter in the user_variable file nova_scheduler_default_filters: - AvailabilityZoneFilter - ComputeFilter - AggregateInstanceExtraSpecsFilter - AggregateNumInstancesFilter - AggregateIoOpsFilter - ComputeCapabilitiesFilter - ImagePropertiesFilter - ServerGroupAntiAffinityFilter - ServerGroupAffinityFilter - NUMATopologyFilter - PciPassthroughFilter nova_pci_alias: - '{ "name": "nvidia", "product_id": "25b6", "vendor_id": "10de" }' =====> how can I add *device_type field here* as per the mail.yaml it only have name,product_id and vendor_id field? Execute: openstack-ansible os-nova-install.yml --tags nova-config --limit <nova api containers> Regards

2 2

[skyline-console] Issue with Skyline Console in Dalmatian Version of OpenStack
by Shubham Kumar Yadav 22 Jan '25

22 Jan '25

Dear Support Team, I hope this message finds you well. I am reaching out to report an issue I am experiencing with the Skyline console in the Dalmatian version of OpenStack. Issue Description: I am unable to list volumes and instances, as well as access volume-related services like Manila. This functionality is critical for my operations. Version Details: I have successfully set up the Skyline console for the Zed version of OpenStack, where everything is functioning as expected. However, the same cannot be said for the Dalmatian version. Troubleshooting Steps Taken: I have checked the service status and confirmed that all necessary services are running. I have attempted to refresh the console and clear the cache, but the issue persists. Request for Assistance: I would appreciate any guidance or troubleshooting steps you could provide to resolve this issue. If there are any logs or additional information you need from my end, please let me know. Also im using same image for both the openstack version - *99cloud/skyline:latest * These are the versions of nova-api & cinder-api *Zed version nova-manage version 26.2.2 cinder-manage version list 21.1.0* *Dalmation versionnova-manage version30.0.1cinder-manage version list* *25.0.0* Thank you for your attention to this matter. I look forward to your prompt response. Best regards, Shubham

1 0

reg trove - issues in deployment
by Rajendar K 22 Jan '25

22 Jan '25

Dear All, I have the following issues while trying trove service. (i) I have installed using kolla ansible and my trove container version is (trove-conductor:2024.1-debian-bookworm) and all my service is running in healthy state. (ii) trove-taskmanger.log as follows 2025-01-22 10:41:54.605 7 ERROR oslo.service.loopingcall File "/var/lib/kolla/venv/lib/python3.11/site-packages/trove/common/utils.py", line 195, in poll_and_check 2025-01-22 10:41:54.605 7 ERROR oslo.service.loopingcall obj = retriever() 2025-01-22 10:41:54.605 7 ERROR oslo.service.loopingcall ^^^^^^^^^^^ 2025-01-22 10:41:54.605 7 ERROR oslo.service.loopingcall File "/var/lib/kolla/venv/lib/python3.11/site-packages/trove/taskmanager/models.py", line 839, in _service_is_active 2025-01-22 10:41:54.605 7 ERROR oslo.service.loopingcall raise TroveError(_("Service not active, status: %s") % status) 2025-01-22 10:41:54.605 7 ERROR oslo.service.loopingcall trove.common.exception.TroveError: Service not active, status: failed to spawn 2025-01-22 10:41:54.605 7 ERROR oslo.service.loopingcall 2025-01-22 10:41:54.624 7 ERROR trove.taskmanager.models [None req-9aede034-a46c-47ec-a149-d7e164fa82e2 cad362f5da0d4f5b8aa87b0650379ed7 4e4b5450f3514da4af3c282d510d9f71 - - - -] Failed to create instance b53d9ebb-2fc6-4927-91c2-f82379b98cfa, error: Service not active, status: failed to spawn.: trove.common.exception.TroveError: Service not active, status: failed to spawn 2025-01-22 10:41:54.636 7 ERROR trove.taskmanager.models [None req-9aede034-a46c-47ec-a149-d7e164fa82e2 cad362f5da0d4f5b8aa87b0650379ed7 4e4b5450f3514da4af3c282d510d9f71 - - - -] Service status: ERROR, service error description: guestagent error: trove.common.exception.TroveError: Service not active, status: failed to spawn 2025-01-22 10:41:54.645 7 ERROR trove.taskmanager.models [None req-9aede034-a46c-47ec-a149-d7e164fa82e2 cad362f5da0d4f5b8aa87b0650379ed7 4e4b5450f3514da4af3c282d510d9f71 - - - -] Trove instance status: ERROR, Trove instance status description: Build error: guestagent timeout.: trove.common.exception.TroveError: Service not active, status: failed to spawn (iii) Does docker required for the configuration of DB or not need in case I use the image trove-master-guest-ubuntu-jammy.qcow2 directly Kindly help me in this regard, thanks Raj

1 0

[magnum] Proposing Jakub Darmach as core reviewer
by Michał Nasiadka 22 Jan '25

22 Jan '25

Hello, I’d like to propose Jakub Darmach (jakub(a)stackhpc.com) as a core reviewer. He has spent quite a good deal of time to get unmaintained branches CI in a green state. He has also contributed some Heat driver patches in the past and is actively reviewing patches (also going the extra mile of updating these patches to be mergable when the author is not available/responsive). Michał Nasiadka mnasiadka(a)gmail.com

3 3

[telemetry] Stepping down from core team
by Yadnesh Kulkarni 22 Jan '25

22 Jan '25

Dear Team, Due to my role change I will no longer be able to contribute to the Telemetry projects. I’ve decided to step down from the core team. Working on the Telemetry projects has been a truly rewarding and enriching learning experience. I’ve thoroughly enjoyed being part of this incredible journey and have gained a lot from collaborating with such talented and supportive individuals. Thank you all for your guidance, collaboration, and support throughout this time. Wishing the team continued success and growth! -- Yadnesh Kulkarni

2 1

[tc][freezer][watcher][release][requirement][oslo] projects need to refresh the DPL model for the next cycle
by Ghanshyam Mann 21 Jan '25

21 Jan '25

Hi All, As you know, we have five projects (listed below) in the DPL model. As per process[1], we need to reset the DPL model every cycle. The project team either needs to opt-in to the DPL model (refer to the document for exact steps[1]) or plan for the PTL election. 1. Freezer: https://review.opendev.org/c/openstack/governance/+/939484 2. Watcher: https://review.opendev.org/c/openstack/governance/+/939488 3. Release: https://review.opendev.org/c/openstack/governance/+/939486 4. Requirement: https://review.opendev.org/c/openstack/governance/+/939487 5. Oslo: https://review.opendev.org/c/openstack/governance/+/939485 [1] https://governance.openstack.org/tc/reference/distributed-project-leadershi… -gmann

1 1

[nova] Seeking Advice on Adding Multiple CPU Models in One Aggregate for OpenStack
by mina.mohammadi367＠gmail.com 21 Jan '25

21 Jan '25

Hello friends, I am currently working on a deployment scenario in OpenStack where I need to group multiple CPU models within a single aggregate. I’m reaching out to the community to ask if anyone has experience with this type of setup or has any advice on best practices. I would greatly appreciate any input from the community regarding potential challenges or recommendations for managing multiple CPU models within a single aggregate. In particular, any advice on ensuring compatibility and optimizing instance scheduling based on traits would be extremely valuable. For reference, I am considering the solution outlined in the CPU Model Selection documentation: https://specs.openstack.org/openstack/nova-specs/specs/train/implemented/cp… Thank you in advance for your time and assistance.

1 0

Assistance with Configuring fdb_age_threshold in OVN with Kolla-Ansible
by Jan Wasilewski 21 Jan '25

21 Jan '25

Hi Stackers, Over the past few days, we encountered an issue during the migration of VMs from a customer environment to our OpenStack cloud. Both environments were connected via a cross-connect network (a VLAN-type network spanning the cloud and the customer environment), which resulted in duplicate MAC addresses in our OVN database. This occurred because the migrated VM retained the same MAC address as previously used in the customer's environment(so "ovn-sbctl list fdb" returned a port which was no-longer used and leads to such duplication) . To address the issue, we used the following command to clear the FDB database: ovn-sbctl --all destroy fdb While researching further, we came across the `fdb_age_threshold` configuration [1], which seemed to be a useful feature to prevent similar issues in the future. We attempted to implement it in our Kolla-Ansible environment by adding the following configuration to ` */etc/kolla/config/neutron/ml2_conf.ini*`: [ovn] fdb_age_threshold = 920 After deploying the changes, however, we noticed that the setting did not take effect in OVN. The configuration only applied successfully after we executed a manual script to propagate the setting directly to OVN [2]. Anyway such change is applicable only for exsisting networks, so it is far from perfect solution. Could you provide guidance on whether this behavior is due to incorrect documentation, an error in our configuration process, or an additional requirement needed to enable this feature? Any insights would be greatly appreciated. Thank you in advance for your support! /Jan Wasilewski **References:** [1] https://docs.openstack.org/neutron/latest/configuration/ml2-conf.html#ovn.f… [2] https://paste.openstack.org/show/b9xUcnG6GXmCdSbSReG0/

2 2

[openstack-ansible] issue
by Danish Khan 21 Jan '25

21 Jan '25

Dear All, Whenever I do any activity like Operating system upgrade of compute nodes or openstack major version update then the name of compute host gets updated. I have my compute node with name compute1,2,3.... but after the activity they sometimes become compute1.openstack.local or compute2.mgmt.local. Due to this I get duplicate resource providers. But only the latest provider works properly. and I had manually unset all the vm from old provider and added then into new provider. Is there a way I can avoid this? means I don't want my compute nodes to get renamed with domain. And is there a way I can unset a vm from all provider and heal them automatically instead adding them into new resource proivder? I tried below docs but the healing part is not working so I go with manual process for all vm which is too time consuming. https://docs.openstack.org/nova/yoga/admin/troubleshooting/orphaned-allocat… Regards, Danish Khan

3 2

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-10)
by Goutham Pacha Ravi 20 Jan '25

20 Jan '25

Hello Stackers, We're 10 weeks away from the 2025.1 coordinated "Epoxy" release [1]. Starting this week, there are several deadlines that project teams have adopted to ensure that code, specifications, and documentation changes are adequately peer-reviewed. As Slawek Kaplonski (slaweq) shared to this mailing list [2], the nomination period for the upcoming Technical Committee and Project Team Leads elections will begin on 2025-02-05 and remain open until 2025-02-19. Early nominations are highly encouraged in case you'll be unavailable during this period. In the last week, the OpenStack Technical Committee selected a community goal to migrate away from the eventlet library across its codebase [3]. As with many community goals, this will be a multi-release goal and needs contributors. Please join the #openstack-eventlet-removal IRC channel on OFTC to participate in the discussion. === Weekly Meeting === Dmitriy Rabotyagov (noonedeadpunk) chaired the TC's weekly IRC meeting on 2025-01-14 [4]. We discussed the maintenance of the "openstackdocstheme" Sphinx plugin and called out some early attempts to switch documentation to a stock theme that's more maintainable and sustainable. We also reviewed a proposal from Freezer project maintainers to remove the project team from the "inactive" teams list [5]. The TC also considered requesting an exception for Freezer to release within 2025.1. In this vein, we also highlighted the need for consistent criteria to move projects out of inactive status and better tooling for indicating project health and activity. The next meeting of the OpenStack Technical Committee is today, 2025-01-21. This meeting will be hosted via IRC on OFTC's #openstack-tc channel. Please find the meeting agenda on the wiki [6]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Propose to select the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/934936 - Rework the eventlet-removal goal proposal | https://review.opendev.org/c/openstack/governance/+/931254 - Add ansible-role-httpd repo to OSA-owned projects | https://review.opendev.org/c/openstack/governance/+/935694 ==== Open for Review ==== - Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 - Retire Freezer DR | https://review.opendev.org/c/openstack/governance/+/938183 - Retire qdrouterd role | https://review.opendev.org/c/openstack/governance/+/938193 - Remove Freezer from inactive state | https://review.opendev.org/c/openstack/governance/+/938938 - Reset the DPL model for oslo project | https://review.opendev.org/c/openstack/governance/+/939485 - Reset the DPL model for Release project | https://review.opendev.org/c/openstack/governance/+/939486 - Reset the DPL model for Requirement project | https://review.opendev.org/c/openstack/governance/+/939487 - Reset the DPL model for Watcher project | https://review.opendev.org/c/openstack/governance/+/939488 - Define 2025 upstream investment opportunities | https://review.opendev.org/c/openstack/governance/+/939507 === Upcoming Events === - 2025-01-28: OpenInfra Board Monthly Meeting: https://board.openinfra.org/ - 2025-02-01: FOSDEM 2025 (https://fosdem.org/2025/) OpenStack's 15th Birthday Celebration - 2025-02-05: Nominations open for 2025.2 TC/PTL Elections: https://governance.openstack.org/election/ - 2025-02-28: 2025.1 ("Epoxy") Feature Freeze and release milestone 3 [1] - 2025-03-06: SCALE 2025 + OpenInfra Days NA (https://www.socallinuxexpo.org/scale/22x) Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] TC/PTL Election dates for the 2025.2 cycle: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] Goal to Remove Eventlet from OpenStack: https://governance.openstack.org/tc/goals/selected/remove-eventlet.html [4] TC Meeting IRC Log 2025-01-14: https://meetings.opendev.org/meetings/tc/2025/tc.2025-01-14-18.00.log.html [5] Remove Freezer from inactive state: https://review.opendev.org/c/openstack/governance/+/938938 [6] TC Meeting Agenda, 2025-01-21: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[Horizon] Need Help - Error with Compress
by info＠patrick-omland.de 20 Jan '25

20 Jan '25

I need help with Horizon; when I run the following command ./manage.py compress, I get the following error: (venv) root@fsn1-controller01 /var/lib/horizon # ./manage.py compress /var/lib/horizon/venv/lib/python3.11/site-packages/debreach/__init__.py:6: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. version_info = version.StrictVersion(__version__).version CommandError: An error occurred during rendering _stylesheets.html: Error: File to import not found or unreadable: /horizon/lib/font_awesome/scss/font-awesome.scss. on line 12:1 of dashboard/scss/horizon.scss from line 6:9 of stdin >> @import "/horizon/lib/font_awesome/scss/font-awesome.scss"; ^ (venv) root@fsn1-controller01 /var/lib/horizon # ll total 124 -rw-r--r-- 1 root root 77 Jan 20 19:13 babel-django.cfg -rw-r--r-- 1 root root 258 Jan 20 19:13 babel-djangojs.cfg -rw-r--r-- 1 root root 233 Jan 20 19:13 bindep.txt -rw-r--r-- 1 root root 600 Jan 20 19:13 CONTRIBUTING.rst drwxr-xr-x 3 root root 4096 Jan 20 19:13 doc -rw-r--r-- 1 root root 579 Jan 20 19:13 HACKING.rst drwxr-xr-x 19 root root 4096 Jan 20 19:15 horizon -rw-r--r-- 1 root root 10143 Jan 20 19:13 LICENSE -rwxr-xr-x 1 root root 831 Jan 20 19:13 manage.py -rw-r--r-- 1 root root 634 Jan 20 19:13 MANIFEST.in drwxr-xr-x 6 root root 4096 Jan 20 19:15 openstack_auth drwxr-xr-x 18 root root 4096 Jan 20 19:15 openstack_dashboard -rw-r--r-- 1 root root 1023 Jan 20 19:13 package.json drwxr-xr-x 8 root root 4096 Jan 20 19:13 playbooks -rw-r--r-- 1 root root 2188 Jan 20 19:13 plugin-registry.csv -rw-r--r-- 1 root root 1920 Jan 20 19:13 README.rst drwxr-xr-x 4 root root 4096 Jan 20 19:13 releasenotes -rw-r--r-- 1 root root 120 Jan 20 19:13 reno.yaml -rw-r--r-- 1 root root 2664 Jan 20 19:13 requirements.txt drwxr-xr-x 5 root root 4096 Jan 20 19:13 roles -rw-r--r-- 1 root root 1937 Jan 20 19:13 setup.cfg -rw-r--r-- 1 root root 698 Jan 20 19:13 setup.py drwxr-xr-x 9 root root 4096 Jan 20 19:15 static -rw-r--r-- 1 root root 379 Jan 20 19:13 test-requirements.txt -rw-r--r-- 1 root root 3198 Jan 20 19:13 test-shim.js drwxr-xr-x 2 root root 4096 Jan 20 19:13 tools -rw-r--r-- 1 root root 7537 Jan 20 19:13 tox.ini drwxr-xr-x 6 root root 4096 Jan 20 19:13 venv (venv) root@fsn1-controller01 /var/lib/horizon # I have installed Horizon in a virtual Python 3 environment (Debian Bookworm) and I also clone the Horizon Github Repo, then I installed all requirements using pip install -r requirements.txt. Anyone have an idea?

1 0

[Horizon] Need Help - Error with Compress
by info＠patrick-omland.de 20 Jan '25

20 Jan '25

I need help with Horizon; when I run the following command ./manage.py compress, I get the following error: (venv) root@fsn1-controller01 /var/lib/horizon # ./manage.py compress /var/lib/horizon/venv/lib/python3.11/site-packages/debreach/__init__.py:6: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. version_info = version.StrictVersion(__version__).version CommandError: An error occurred during rendering _stylesheets.html: Error: File to import not found or unreadable: /horizon/lib/font_awesome/scss/font-awesome.scss. on line 12:1 of dashboard/scss/horizon.scss from line 6:9 of stdin >> @import "/horizon/lib/font_awesome/scss/font-awesome.scss"; ^ (venv) root@fsn1-controller01 /var/lib/horizon # ll total 124 -rw-r--r-- 1 root root 77 Jan 20 19:13 babel-django.cfg -rw-r--r-- 1 root root 258 Jan 20 19:13 babel-djangojs.cfg -rw-r--r-- 1 root root 233 Jan 20 19:13 bindep.txt -rw-r--r-- 1 root root 600 Jan 20 19:13 CONTRIBUTING.rst drwxr-xr-x 3 root root 4096 Jan 20 19:13 doc -rw-r--r-- 1 root root 579 Jan 20 19:13 HACKING.rst drwxr-xr-x 19 root root 4096 Jan 20 19:15 horizon -rw-r--r-- 1 root root 10143 Jan 20 19:13 LICENSE -rwxr-xr-x 1 root root 831 Jan 20 19:13 manage.py -rw-r--r-- 1 root root 634 Jan 20 19:13 MANIFEST.in drwxr-xr-x 6 root root 4096 Jan 20 19:15 openstack_auth drwxr-xr-x 18 root root 4096 Jan 20 19:15 openstack_dashboard -rw-r--r-- 1 root root 1023 Jan 20 19:13 package.json drwxr-xr-x 8 root root 4096 Jan 20 19:13 playbooks -rw-r--r-- 1 root root 2188 Jan 20 19:13 plugin-registry.csv -rw-r--r-- 1 root root 1920 Jan 20 19:13 README.rst drwxr-xr-x 4 root root 4096 Jan 20 19:13 releasenotes -rw-r--r-- 1 root root 120 Jan 20 19:13 reno.yaml -rw-r--r-- 1 root root 2664 Jan 20 19:13 requirements.txt drwxr-xr-x 5 root root 4096 Jan 20 19:13 roles -rw-r--r-- 1 root root 1937 Jan 20 19:13 setup.cfg -rw-r--r-- 1 root root 698 Jan 20 19:13 setup.py drwxr-xr-x 9 root root 4096 Jan 20 19:15 static -rw-r--r-- 1 root root 379 Jan 20 19:13 test-requirements.txt -rw-r--r-- 1 root root 3198 Jan 20 19:13 test-shim.js drwxr-xr-x 2 root root 4096 Jan 20 19:13 tools -rw-r--r-- 1 root root 7537 Jan 20 19:13 tox.ini drwxr-xr-x 6 root root 4096 Jan 20 19:13 venv (venv) root@fsn1-controller01 /var/lib/horizon # I have installed Horizon in a virtual Python 3 environment (Debian Bookworm) and I also clone the Horizon Github Repo, then I installed all requirements using pip install -r requirements.txt. Anyone have an idea?

1 0

How to know the openstack client's default microversion?
by berndbausch＠gmail.com 20 Jan '25

20 Jan '25

Without the version option e.g. --os-compute-api-version, the openstack client submits API requests with certain default microversions. The precise microversions vary with the openstack client's version and the specific task. For example, the --debug option reveals that openstack client 7.1.3 uses Nova microversion 2.89 when attaching a volume to an instance. Is there a simpler way than --debug to find out which microversions the client uses? Is there a command, or perhaps a website where this is documented? Thanks for your ideas! Bernd.

2 1

[openstack-ansible] : libvirtd debug logs after Wallaby upgrade
by Rambo Rambo 20 Jan '25

20 Jan '25

Hi Team I have recently done Victoria to Wallaby upgrade on my openstack-ansible installation. After the upgrade we observe that /var/log/libvirt/ size on all the computes was growing due to libvirtd.log file. Further checking this file it can be seen that there are debug logs. 2025-01-19 11:15:20.817+0000: 2943565: *debug *: virNetlinkEventCallback:862 : dispatching to max 0 clients, called from event watch 7 2025-01-19 11:15:20.817+0000: 2943565:* debug* : virNetlinkEventCallback:876 : event not handled. 2025-01-19 11:15:20.821+0000: 2943605: *debug :* udevHandleOneDevice:1492 : udev action: 'add' ... libvirtd configuration file on compute shows log_level=1 cat libvirtd.conf # Ansible managed # enabling debug mode according to http://wiki.libvirt.org/page/DebugLogs log_level = 1 log_filters="3:remote 4:event 3:json 3:rpc" log_outputs="1:file:/var/log/libvirt/libvirtd.log" listen_tls = 0 listen_tcp = 0 unix_sock_group = "libvirt" unix_sock_ro_perms = "0777" unix_sock_rw_perms = "0770" auth_unix_ro = "none" auth_unix_rw = "none" auth_tcp = "sasl" No related parameter was changed/updated in user_variable file during the upgrade? Any information what could have enabled the debug logs for libvirtd on all the computes? Also how can I turn-off this using the openstack-ansible and what could be impact during the procedure? Regards

2 3

Openstack Ansible
by engineer2024 20 Jan '25

20 Jan '25

It seems that the ssh to containers from the deploy node, is removed in the caracal release by default in OSA. The new containers don't have the ssh service inside them. Is there a way to enable it via a variable ?

2 2

[neutron] Bug deputy week 3 2025 (2025-01-13 - 2025-01-19)
by Lajos Katona 20 Jan '25

20 Jan '25

Hi Neutrinos, The bug list for week 3 of 2025. * Critical ** https://bugs.launchpad.net/neutron/+bug/2094970 (rally ovn job timing out with eventlet 0.38.2) *** https://review.opendev.org/c/openstack/neutron/+/939315 Merged * High ** https://bugs.launchpad.net/neutron/+bug/2094736 ([OVN] Missing ``LogicalSwitchPortUpdateUpEvent`` when a port is bound) *** WIP: https://review.opendev.org/c/openstack/neutron/+/939345 ** https://bugs.launchpad.net/neutron/+bug/2094810 (neutron-status upgrade check fails on checking if ovn_alembic_version table exists) *** https://review.opendev.org/c/openstack/neutron/+/939248 ** https://bugs.launchpad.net/neutron/+bug/2094842 ("ovs.db.error.Error: ovsdb error: 0 values when type requires between 1 and 9223372036854775807" when router is attached to network without subnet ) *** Unassigned ** https://bugs.launchpad.net/neutron/+bug/2095000 (ovs-agent: Failed to store metadata for trunk ...: Cannot find Bridge with name=tbr-... ) Assigned ** https://bugs.launchpad.net/neutron/+bug/2095044 (test_ip_lib calls to sudo and fails (sometimes?)) *** https://review.opendev.org/c/openstack/neutron/+/939435 Merged ** https://bugs.launchpad.net/neutron/+bug/2095167 (BW limit not applied to external/provider network) *** https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/939539 ** https://bugs.launchpad.net/neutron/+bug/2095180 (test_agent_metadata_port_dhcp_reenable_event fails when ovsdb-server combines create and later update into a single create event for monitor) *** https://review.opendev.org/c/openstack/neutron/+/939542 ** https://bugs.launchpad.net/neutron/+bug/2095195 ( VM fails to receive IPv4 from DHCP agent because the agent has not updated the network config for dnsmasq after port was created) ** https://bugs.launchpad.net/neutron/+bug/2095196 (functional: test_virtual_port_host_update failed due to ovsdb SB transaction timeout, "Unreasonably long 25512ms poll interval (0ms user, 26ms system)" in ovsdb-server log) *** https://review.opendev.org/c/openstack/neutron/+/939558 ** https://bugs.launchpad.net/neutron/+bug/2095224 (Functional jobs randomly timed out, possible load issues on the host ) *** perhaps duplicate of bug/2095196 ( https://bugs.launchpad.net/neutron/+bug/209519) * Medium ** https://bugs.launchpad.net/neutron/+bug/2094846 (neutron.tests.functional.services.trunk.drivers.ovn.test_trunk_driver.TestOVNTrunkDriver.test_subport_delete fails because remove_subports fails to update OVN db due to revision number inconsistency) *** Unassigned ** https://bugs.launchpad.net/neutron/+bug/2095084 ([OVN] Error in ``_delete_router_remove_external_gateways``: "'NoneType' object has no attribute 'network_id'") *** https://review.opendev.org/c/openstack/neutron/+/939451 ** https://bugs.launchpad.net/neutron/+bug/2095097 (500 error creating resource with emoji for name) Unassigned ** https://bugs.launchpad.net/neutron/+bug/2095152 (ovs-agent: Leftover tpi/spi interfaces after VM boot/delete with trunk port(s)) Unassigned ** https://bugs.launchpad.net/neutron/+bug/2095185 test_legacy_router_conntrack_helper failed as "neutron_lib.exceptions.BridgeDoesNotExist: Bridge test-bre0e2da16 does not exist" when router attempted to plug interface *** Unassigned, Was seen on stable, but can happen on master * Low ** https://bugs.launchpad.net/neutron/+bug/2095091 (test_metadata_ipv6_only_network failed looking for QUERY_MSG) Unassigned Lajos Katona (lajoskatona)

1 0

[glance][ops] proposal to remove the glance-scrubber
by Brian Rosmaita 19 Jan '25

19 Jan '25

Hello Glance users, The Glance project team wants to determine whether anyone is using the glance-scrubber utility [0]. If not, we are thinking of deprecating it this cycle to be removed in the appropriate future cycle. If you have not previously heard of the glance-scrubber, that's most likely because it's only useful for particular deployment configurations of which yours is not one. See the doc [0] for details if you are curious. Our suspicion is that the glance-scrubber may have outlived its usefulness for modern OpenStack configurations. (The last time I remember it being discussed at a PTG was during the snowstorm in Dublin, which I believe was the Rocky development cycle). On the other hand, the team also has some ideas for improving the scrubber, but there's no point doing that if it's not actually being used in the first place. So if removal of the glance-scrubber would negatively affect you, please respond to this email so we can get some data points. Thanks! [0] https://docs.openstack.org/glance/latest/cli/glancescrubber.html

2 2

[magnum] GPU support with magnum
by Satish Patel 18 Jan '25

18 Jan '25

Folks, We are running magnum with openstack to spin up k8s clusters and everything works as expected. Now I want GPU support so we can do some AI/ML stuff with k8s. Does magnum support GPU and how does it work? In the past I used GPU in passthrough mode to expose hardware to VMs but not sure how it works for k8s and what are the challenges?

5 16

[neutron][upgrades] Linuxbridge driver removal and migration
by Brian Haley 17 Jan '25

17 Jan '25

Hi Stackers, In 2022, during the Zed cycle, the Neutron team took a step at marking some items as experimental. One of those was the Linuxbridge driver. The reason was due to it being unmaintained for a number of cycles, and no one was able to take on its ownership. The implication of this decision was that it was consider deprecated, even if not given an official warning message. In doing this, all gate jobs were moved into the experimental queue, feature-parity with other drivers was deemed unnecessary, and bug fixing was considered best-effort. Since then, both major distros have stopped supporting new deployments using Linuxbridge, and have been mainly focused on OVN. So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the code from the tree [1]. After 5 cycles of being considered experimental without any investment it just makes sense. We plan on doing this in the current Epoxy cycle. We realize that there are still deployments using Linuxbridge, and hopefully they have been looking at migration strategies since we originally marked the code experimental. This email is another push to the user community to start looking at this, especially if you are planning any new deployments. There has been at least one migration guide written at [2] (thanks Jim!), and at this point I would encourage those still using Linuxbridge to look at it and start asking any questions they have so we have the chance to make it better and can make that process easier. Thanks for reading, -Brian, Neutron PTL [0] https://review.opendev.org/c/openstack/neutron/+/845181 [1] https://review.opendev.org/c/openstack/neutron/+/927216 [2] https://www.jimmdenton.com/migrating-lxb-to-ovn/

11 14

openstack ssl
by engineer2024 17 Jan '25

17 Jan '25

The present model for openstack API services uses keystone for authentication mechanism for the REST API. is it possible to test the api calls directly using the server/port of a API service, bypassing the keystone URI ? does this require any modification in the configuration of the openstack service ? Thanks

1 0

[neutron] Using address scopes in a DVR environment breaks floating IPs
by Lukas Steiner 17 Jan '25

17 Jan '25

Hi all, I hope to get some advice here if we’re doing something wrong or ran into a bug. We have an OpenStack environment (wallaby) with Distributed Virtual Router (DVR) enabled (compute nodes use DVR_NO_EXTERNAL agent mode, network nodes use DVR_SNAT) and we would like to onboard our provider network to a subnet pool part of an address scope to allow routed self-service networks. But as soon as the provider network is part of an address scope, the floating IP feature stops working. After debugging we found that adding the network to an address scope results in an additional set of firewall rules in the router and snat network namespaces which blocks cross-scope traffic. But floating IPs should be the exception to that and there are indeed rules that explicitly allow them by setting a mark in the iptables mangle table: -A neutron-l3-agent-floatingip -d <floating-ip>/32 -i qg-<random-id> -j MARK --set-xmark 0x4000000/0xffff0000 We can find these rules in the qrouter namespaces, but they’re missing in the snat namespaces. If we add the rule manually to the snat namespace, the floating IP is working again. If we switch the compute nodes to DVR agent mode, it also works, as the snat namespace is not used. I have already searched for bugs and changes in the DVR router code since wallaby but can’t find anything which is not already patched in wallaby. So, I’m wondering if we have an unsupported setup with combining dynamic routing with DVR and centralized network nodes or facing a long running neutron bug. Maybe someone has a similar setup or can confirm that this use case should be supported? Regards, Lukas

1 0