April 2025 - openstack-discuss - lists.openstack.org

[kolla-ansible] deploying epoxy release issues
by Satish Patel 23 Apr '25

23 Apr '25

Folks, For the experiment, I am deploying epoxy in the lab and getting some nova related issues. not sure if they are bugs or just config tuning. #BUG 1 placement_api container failed to start because of uWSIG provider issue. I have changed to apache that fixed the issue. placement_api_backend: "apache" placement_wsgi_provider: "apache" # BUG 2 or Failed it this point. TASK [nova-cell : Waiting for nova-compute services to register themselves] ****************************************************************************************************************************************** An exception occurred during task execution. To see the full traceback, use -vvv. The error was: json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) fatal: [vsan2]: FAILED! => {"msg": "Unexpected failure during module execution: Expecting value: line 1 column 1 (char 0)", "stdout": ""} # BUG 3 inside the nova-computer container I didn't see any service or process related privsep-helper --config-file /etc/nova/nova.conf is this something new or missed by bug or config? (xenv) root@vsan2:/etc/kolla# docker exec -it -u0 nova_compute bash (nova-compute)[root@vsan2 /]# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND nova 1 0.0 0.0 2644 956 ? Ss 08:28 0:00 dumb-init --single-child -- kolla_start nova 7 1.0 0.0 1883120 188576 ? Sl 08:28 0:15 /var/lib/kolla/venv/bin/python3 /var/lib/kolla/venv/bin/nova-compute root 611 1.0 0.0 7636 4128 pts/2 Ss 08:52 0:00 bash root 627 0.0 0.0 10072 1580 pts/2 R+ 08:52 0:00 ps aux

3 4

[ops][upgrades][slurp] Seeking OpenStack Upgrade Case Studies
by Allison Price 22 Apr '25

22 Apr '25

Hi everyone, We have now published two case studies from OpenStack users who have implemented and are benefiting from the SLURP upgrade process[1]: Cleura[2] and Indiana University[3] I wanted to follow up to see if there are other organizations who have implemented the SLURP upgrade process who would like to tell your story? If we can get a few more, I would love to schedule an OpenInfra Live to deep dive into the improvements made around OpenStack upgrades and what users stuck on older releases should know. If you are interested, please let me know. And even if you’re not but you’re still using OpenStack—please remember to take the OpenStack User Survey[4] so we can learn more! Thanks! Allison [1] https://docs.openstack.org/project-team-guide/release-cadence-adjustment.ht… [2]https://superuser.openinfra.org/articles/streamlining-openstack-upgrades-… [3] https://superuser.openinfra.org/articles/streamlining-openstack-upgrades-a-… [4] https://www.openstack.org/user-survey

3 7

How to config DPDK compute in OVN
by dangerzone ar 22 Apr '25

22 Apr '25

Hi....as far I understand ovs does support dpdk compute to be deployed. I'm referring to the guideline ' *https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html <https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html>* ' ... It's too brief.. May I know how to config dpdk compute in OVN networking openstack? Hope someone could help what is the config to be done.... Currently compute is run without dpdk over openstack train ovn based. Please need some info on how I can proceed. Thank you

2 1

[kolla-ansible] Nova + ceph cache mode
by Michael Knox 22 Apr '25

22 Apr '25

Hey Folks, Is it possible to use "cache=none" and "io=native" values with a kolla-ansible deployed cloud that uses a Ceph backend? Looks like that it's hard coded to use writeback for caching when the Nova backend is rbd. No globals.yaml overrides. https://github.com/openstack/kolla-ansible/blob/8d6b5de4c19681dd6cbec45d803… Cheers Michael

3 2

Using IOThreads
by Vahric Muhtaryan 22 Apr '25

22 Apr '25

Hello Everyone, I saw that using IO Thread for instance was planned but somehow implementation is deferred. https://blueprints.launchpad.net/nova/+spec/iothreads-for-instances Are there any updates regarding the schedule for IOThread implementation? Regards Vahric

3 2

[neutron] Bug deputy week 16 (April 14 - April 20)
by Lajos Katona 22 Apr '25

22 Apr '25

Hi Neutrinos, I send the bugs from week 16 (From April 14 to April 20). *High* * test_assert_pings_during_br_phys_setup_not_lost_in_vlan_to_flat functional tests randomly fails ( https://bugs.launchpad.net/neutron/+bug/2107775 ) *Medium* * When a new security group rule is created, logging is not properly configured (https://bugs.launchpad.net/neutron/+bug/2107446 ): Fix is committed: https://review.opendev.org/c/openstack/neutron/+/947324 , but I was not able to reproduce it in my local env. * Disable gateway error with flow based DHCP ( https://bugs.launchpad.net/neutron/+bug/2107552 ) Fix is under review ( https://review.opendev.org/c/openstack/neutron/+/947560 ) *RFE*: * Same Host Traffic Leaks in Neutron DVR When Using BGP ( https://bugs.launchpad.net/neutron/+bug/2107634 ) *Fix committed* * [whitebox-neutron-tempest-plugin] QoS BW limit tests after migration should check the compute of sender and receiver ( https://bugs.launchpad.net/neutron/+bug/2107368 ) *Incomplete* * router ha was split brain when restarting l3 agent docker ( https://bugs.launchpad.net/neutron/+bug/2107323 ): More information is necessary the logs contain any relevant information. Best wishes Lajos Katona (lajoskatona)

1 0

[dalmatian]display of "enable_dhcp" in horizon
by Franck VEDEL (UGA) 22 Apr '25

22 Apr '25

2 1

rally/tempest
by jacek.grodkowski＠asseco.cloud 22 Apr '25

22 Apr '25

Hi I have problem with rally/tepest - docker container rally - release 4.1.0 openstack environment is correct visible from rally tempest plugin is correct visible from rally no matter, does rally is running from rally user or root user every time after : rally verify start i receive 2025-04-10 13:13:48.318 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context tempest@default setup() finished in 6.84 sec 2025-04-10 13:13:48.318 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context testr@default setup() finished in 0.03 msec 2025-04-10 13:13:50.036 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context testr@default cleanup() started 2025-04-10 13:13:50.037 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context testr@default cleanup() finished in 0.19 msec 2025-04-10 13:13:50.037 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context tempest@default cleanup() started 2025-04-10 13:13:54.021 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context tempest@default cleanup() finished in 3.98 sec 2025-04-10 13:13:54.030 1139 INFO rally.api [-] Verification (UUID=d92179d4-93d4-4805-8703-9861d9ce55cc) has been successfully finished for deployment 'my_openstack' (UUID=f4746f40-8527-4e79-8ce7-9196544db770)! ====== Totals ====== Ran: 0 tests in 0.000 sec. - Success: 0 - Skipped: 0 - Expected failures: 0 - Unexpected success: 0 - Failures: 0 Using verification (UUID=d92179d4-93d4-4805-8703-9861d9ce55cc) as the default verification for the future operations. rally test - json files, have correct results when i'm using tempest in standalone version i have no problem with making tests

1 0

[PTG] Keystone summary
by Artem Goncharov 22 Apr '25

22 Apr '25

Hey, Sorry for being late. Here comes the summary from Keystone team discussions during the PTG # python-keystoneclient deprecation Following what other services are doing python-keystoneclient is going to be deprecated as a standalone entity. Work in OSC is currently underway to complete the switch to using OpenStackSDK. We want to deprecate python-keystoneclient (another codebase being duplicated) but we also see many services relying on it. We will evaluate the possibilities we have here. # Switch to the DPL model We were discussing whether it makes sense for the Keystone team to switch to the DPL model, but decided to stick to the PTL model while still formally sharing responsibilities among the team members. # External OAuth2.0 Greg gave an update of the current state of the work. We discussed some corner cases as well as tried to figure out which cases (so to say deployment types) it is suitable for and which not. At the moment this approach is suitable mostly to only certain cases # Launchpad maintenance We discussed (and performed) cleanup of the launchpad teams and removed people that are not active anymore (thanks to them for doing that before) # Service accounts Certain future use cases were discussed where introduction of the "service account" concept may be useful (similarly to what they are in K8). I am continuing prototyping on that in my federation rework and will present results once something reasonable is achieved. Major use case for service accounts may be: - workload authentication (like GitHub action, GitLab CI, etc) where a certain workload should be able to authenticate with Keystone without hardcoding a regular "user" account with the password or application credentials - something similar to the AWS STS, or better to say possibility for OpenStack services (in this example Nova) to request a token for the "service account" that can be provisioned into the VM to allow workload inside the VM to auth into the cloud # Reimplementing Keystone in Rust (with Federation rework and advanced auth based on security keys/passkeys/yubikey) I provided an update of the state of reimplementation of Keystone in Rust with the numbers describing performance improvements (10x-100x depending on the use case). Demo for the yubikey auth was given some time ago separately. We discussed how is it possible to consider Keystone following a microservices approach and for the CSPs to deploy Rust reimpl in parallel to the python keystone to start using reworked federation as well as advanced auth flows (auth with the security key) # Ephemeral credentials This discussion was tightly coupled with the previous discussions on OAuth2, service accounts and federation rework. Sadly we are currently not able to implement something similar to the AWS STS with assigning limited scope tokens before we address other issues and introduce service accounts and further explore alternative policy enforcement approaches # OpenPolicyAgent (as an extension over the oslo.policy) Back in 2018 an idea of adding support for OpenPolicyAgent into the oslo.policy was presented. This time we are much further. There is an oslo.policy plugin, converter of policies from the code to the OpenPolicyAgent (rego) language together with automatic tests generation (as well as hacks for Neutron). There is now even the first CSP rolling it out in production. This step allows CSP better integration of OpenStack with other offerings (K8, Ceph, etc) while offering huge flexibility and fine-granular access control desperately desired by CSPs and full authz audit log. Thanks to all participants. Hope to see you during our regular meetings. Keep on doing your great work :-) Regards, Artem

1 0

[publiccloud-sig] Next meeting of Public Cloud SIG - April 23rd at 0700 UTC
by Felix Kronlage-Dammers 22 Apr '25

22 Apr '25

Hi everyone, This upcoming Wednesday (April 23rd) the next meeting of the publiccloud-sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig (yes, we're back on the summer schedule) See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! cheers felix -- Felix Kronlage-Dammers Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0