May 2025 - openstack-discuss - lists.openstack.org

[release] Release countdown for week R-19
by Thierry Carrez 16 May '25

16 May '25

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

1 0

[Kolla-Ansible][DockerImages] - Failing at start
by Victor Sartori 16 May '25

16 May '25

Hello All, Some containers are failing to start. All of them exhibit the same behavior: ``` + echo 'Running command: '\''uwsgi /etc/nova/nova-api-uwsgi.ini'\''' Running command: 'uwsgi /etc/nova/nova-api-uwsgi.ini' + exec uwsgi /etc/nova/nova-api-uwsgi.ini /usr/local/bin/kolla_start: line 27: exec: uwsgi: not found ``` Could this issue be related to a message posted in the OpenStack IRC? ``` -opendevstatus/#openstack- NOTICE: Setuptools 80.7.0 broke python package installs for many, affecting CI jobs. That release has been yanked, and it should be safe to recheck failed changes. ``` I see errors in the following containers: - quay.io/openstack.kolla/nova-scheduler:2024.2-ubuntu-noble - quay.io/openstack.kolla/placement-api:2024.2-ubuntu-noble - quay.io/openstack.kolla/cinder-volume:2024.2-ubuntu-noble It's likely that any container relying on uwsgi will fail. Environment: Ubuntu 24.04.2 Kernel 6.8.0-59-generic Docker CE 28.1.1 Kolla version: kolla-ansible 20.1.0.dev10 Any help?

1 0

[Kolla-Ansible][Magnum] Vexxhost CAPI no longer working
by Oliver Weinmann 16 May '25

16 May '25

Hi all, a couple of weeks ago I updated the containers in my 2023.2 release. kolla-ansible pull kolla-ansible deploy since then the Vexxhost driver in Magnum is no longer working. I have clusters stuck in provisioning and deleting: $ kubectl get cluster -A NAMESPACE NAME CLUSTERCLASS PHASE AGE VERSION magnum-system kube-6r0du magnum-v0.26.0 Provisioning 20d v1.26.7 magnum-system kube-7ljg3 magnum-v0.26.0 Provisioning 18d v1.26.7 magnum-system kube-csf6s magnum-v0.13.4 Deleting 71d v1.26.7 I believe this is due to a versionn mismatch. Many different tools are involved here. All pods in the KIND Management cluster are running: $ kubectl -n kube-system get pods NAME READY STATUS RESTARTS AGE coredns-76f75df574-lfckv 1/1 Running 5 (2d23h ago) 71d coredns-76f75df574-n85fv 1/1 Running 5 (2d23h ago) 71d etcd-magnumcapi-control-plane 1/1 Running 5 (2d23h ago) 71d kindnet-jtdtm 1/1 Running 5 (2d23h ago) 71d kube-apiserver-magnumcapi-control-plane 1/1 Running 5 (2d23h ago) 71d kube-controller-manager-magnumcapi-control-plane 1/1 Running 10 (2d23h ago) 71d kube-proxy-qwjc8 1/1 Running 5 (2d23h ago) 71d kube-scheduler-magnumcapi-control-plane 1/1 Running 9 (2d23h ago) 71d There is nothing obvious in the capi or capo logs. Is there someone that is currently running 2023.2 or newer with the Vexxhost CAPI driver? Would be great if you could share the versions of: Management Cluster $ kind --version kind version 0.22.0 $ export KUBECONFIG=~/config $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME magnumcapi-control-plane Ready control-plane 71d v1.29.2 172.18.0.2 <none> Debian GNU/Linux 12 (bookworm) 5.14.0-503.38.1.el9_5.x86_64 containerd://1.7.13 $ kubectl get provider -A NAMESPACE NAME AGE TYPE PROVIDER VERSION capi-kubeadm-bootstrap-system bootstrap-kubeadm 71d BootstrapProvider kubeadm v1.9.5 capi-kubeadm-control-plane-system control-plane-kubeadm 71d ControlPlaneProvider kubeadm v1.9.5 capi-system cluster-api 71d CoreProvider cluster-api v1.9.5 capo-system infrastructure-openstack 71d InfrastructureProvider openstack v0.10.8 The magnum pods: ~]# podman exec -it magnum_conductor bash ()[ /]$ pip list | grep api magnum-cluster-api 0.26.0 ()[ /]$ helm version version.BuildInfo{Version:"v3.13.2", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"clean", GoVersion:"go1.20.10"} ~]# podman exec -it magnum_api bash ()[ /]$ pip list | grep api magnum-cluster-api 0.26.0 ()[ /]$ helm version version.BuildInfo{Version:"v3.13.2", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"clean", GoVersion:"go1.20.10"} ()[ /]$ Cheers, Oliver

1 0

[neutron] Neutron drivers meeting cancelled today
by Rodolfo Alonso Hernandez 16 May '25

16 May '25

Hello Neutrinos: Due to the lack of agenda [1], today's meeting is cancelled. Have a nice weekend! [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda

1 0

[openstack][neutron] Using external network for another project
by Nguyễn Hữu Khôi 15 May '25

15 May '25

Hello. I created an external network for a specified project but I cannot create instances with the external network on this tenant. I must create RBAC Policies with shared and external policies then my instances can get IP addresses and run properly. Is it normal? Pls correct me if I am wrong Thank you. Nguyen Huu Khoi

6 19

[neutron][ml2/ovn] unintended changes in trunk status ACTIVE
by Bence Romsics 15 May '25

15 May '25

Hi Neutron Team, A heads up to OVN folks: We believe we have a problem in Neutron that we move a trunk to ACTIVE status too early (changing the meaning of status=ACTIVE) - already after its parent port is updated to ACTIVE instead of waiting for all of its ports (parent and sub) to be processed. We discovered this while working on this bug: https://bugs.launchpad.net/neutron/+bug/2095152 The problem was introduced by this patch: https://review.opendev.org/c/openstack/neutron/+/853779 Which was intended to be a fix for ml2/ovn leaving a trunk in DOWN after live migration. However that patch affected all backends. And affected not just live migration, but create too. We have proposed the following patch to limit the effect to ml2/ovn (but did not yet find a way to avoid affecting create): https://review.opendev.org/c/openstack/neutron/+/949217 However due to ml2/ovn's handling of trunk subports (not cascading the parent's binding:host update to all subports in the neutron api layer) I don't know how this should be fixed for ml2/ovn. Maybe a clever wait in the OVN databases could solve this. People with better OVN knowledge may want look into this. You're also welcome to review our proposed patches, including this os-vif change to prevent a resource leak in ml2/ovs when a trunk is already deleted on server side when the agent is still processing its create: https://review.opendev.org/c/openstack/os-vif/+/949736 Thanks, Bence (rubasov)

1 0

Inquiry About Cloud applications Deployment Methods and Current Best Practices
by Saranraj M 14 May '25

14 May '25

Dear OpenStack Community, I hope this message finds you well. I am currently exploring OpenStack deployment strategies for our infrastructure and wanted to reach out to the community for guidance. Could you kindly share insights on the different deployment methods commonly used within the OpenStack ecosystem (e.g., DevStack, Kolla-Ansible, TripleO, etc.)? Additionally, I would like to understand which method is currently most preferred or widely adopted in production environments, along with any pros and cons you've experienced. Your input will be highly valuable in helping us choose the right path for our deployment. Looking forward to your recommendations and experiences. Thanks & Regards Associate Software Engineer Saranraj.M Ph No: (+91) 9360409252 Email: mailto:saranraj.m@zybisys.com Zybisys Consulting LLP | NSA Tower, No. 1B Akila Nagar, Thiruvanaikoil, Tamilnadu, Trichy, India-620005 http://zybisys.com/ ReplyReply AllForwardEdit as new Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

3 2

[horizon][memcached]
by Kamil Madac 14 May '25

14 May '25

I have deployed openstack 2024.2 with kolla-ansible in HA setup with 3 control nodes. Everything works without issues, but when I stop memcached node with IP address 192.168.56.12 (or when node goes down), it is not possible to login to Horizon with error message: Something went wrong! An unexpected error has occurred. Try refreshing the page. If that doesn't help, contact your local administrator. In horizon log I have an error message: 2025-05-12 18:05:37.406588 Internal Server Error: / 2025-05-12 18:05:37.406613 Traceback (most recent call last): 2025-05-12 18:05:37.406615 File "/var/lib/kolla/venv/lib64/python3.9/site-packages/django/core/handlers/exception.py", line 55, in inner 2025-05-12 18:05:37.406617 response = get_response(request) 2025-05-12 18:05:37.406619 File "/var/lib/kolla/venv/lib/python3.9/site-packages/horizon/middleware/simultaneous_sessions.py", line 30, in __call__ 2025-05-12 18:05:37.406621 self._process_request(request) 2025-05-12 18:05:37.406623 File "/var/lib/kolla/venv/lib/python3.9/site-packages/horizon/middleware/simultaneous_sessions.py", line 37, in _process_request 2025-05-12 18:05:37.406625 cache_value = cache.get(cache_key) 2025-05-12 18:05:37.406627 File "/var/lib/kolla/venv/lib64/python3.9/site-packages/django/core/cache/backends/memcached.py", line 75, in get 2025-05-12 18:05:37.406628 return self._cache.get(key, default) 2025-05-12 18:05:37.406630 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/hash.py", line 347, in get 2025-05-12 18:05:37.406632 return self._run_cmd("get", key, default, default=default, **kwargs) 2025-05-12 18:05:37.406634 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/hash.py", line 322, in _run_cmd 2025-05-12 18:05:37.406636 return self._safely_run_func(client, func, default_val, *args, **kwargs) 2025-05-12 18:05:37.406637 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/hash.py", line 199, in _safely_run_func 2025-05-12 18:05:37.406639 result = func(*args, **kwargs) 2025-05-12 18:05:37.406640 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/base.py", line 687, in get 2025-05-12 18:05:37.406642 return self._fetch_cmd(b"get", [key], False, key_prefix=self.key_prefix).get( 2025-05-12 18:05:37.406644 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/base.py", line 1133, in _fetch_cmd 2025-05-12 18:05:37.406645 self._connect() 2025-05-12 18:05:37.406647 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/base.py", line 424, in _connect 2025-05-12 18:05:37.406648 sock.connect(sockaddr) 2025-05-12 18:05:37.406650 ConnectionRefusedError: [Errno 111] Connection refused so horizon tries to connect to memcached node which is down. I have default kolla-ansible config with enabled memcached and horizon config is following: SESSION_ENGINE = 'django.contrib.sessions.backends.cache' CACHES['default']['LOCATION'] = ['192.168.56.11:11211','192.168.56.12:11211 ','192.168.56.21:11211'] When I stop any other memcached node, horizon is working without issues. Why is that exact node important for the horizon? Does anyone else have the same experience? Thanks for any advice. -- Kamil Madac

4 6

[nova] os-traits release?
by Michael Still 13 May '25

13 May '25

Hi, I tried on IRC but it didn't work out. I realised the other day that I still need an os-traits release for the sound and USB traits that I added a while ago in support of my VDI work. I need those to land before I can really do much more in Nova with the VDI patches. I looked at proposing a release myself, but I couldn't find any documentation on how to actually run the tools for a release independent release. So... Either are there docs on how to do that thing, or could someone do it for me? Thanks, Michael

2 1

[tempest][swift][ceph][radosgw] debugging intermittent failures of test_upload_too_many_objects
by Michael Sherman 13 May '25

13 May '25

In our clouds, we're using ceph rgw to provide the s3 and swift object store interfaces. Recently, we began running non-admin tempest smoke tests against the live clouds, and observe intermittent failures for the object store test_upload_too_many_objects test, where the rgw seemingly fails to enforce the number of objects quota. Tempest is running on the most recent master commit, cloud deployed via Kolla ansible 2023.1, and ceph currently on Pacific, deployed via cephadm. It's not a critical issue in our case, but I'd like some advice on getting to the bottom of it. Thanks! Mike Sherman

1 0