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

Guidance related to Patch Management in Openstack-2024.1 (caracal)
by Shalini Srivastava 19 May '25

19 May '25

Hello Sir, I need to implement Security update that is Patch management, Vulnerability Management to my Openstack environment that is 2024.1 (Caracal release). The services needs to upgrade as well as update according to the upper constraints available for the given release. Please guide me the steps/procedure for the same. Hope to hear from you soon. Thanks & Regards, Shalini Srivastava Project Associate /प्रोजेक्ट एसोसिएट Centre for Development of Advanced Computing(C-DAC) / प्रगत संगणन विकास केन्द्र(सी-डैक) Tidel Park”, 8th Floor, “D” Block, (North &South) / “टाइडल पार्क”,8वीं मंजिल, “डी” ब्लॉक, (उत्तर और दक्षिण) No.4, Rajiv Gandhi Salai / नं.4, राजीव गांधी सलाई Taramani / तारामणि Chennai / चेन्नई – 600113 Ph.No.:044-22542226/27 Fax No.: 044-22542294 ------------------------------------------------------------------------------------------------------------ [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------

1 0

[neutron] Bug deputy report (week starting on May 12)
by Bernard Cafarelli 19 May '25

19 May '25

Hey neutrinos, here is the list of bugs reported last week Overall a quiet week, bugs are assigned with proposed (or merged already) patch, except a CI failure report (no immediate action needed, mostly for tracking if the failure reappears) High * Neutron endpoint options are not applied - https://bugs.launchpad.net/neutron/+bug/2110488 ovn-octavia-provider similar to a fixed Octavia issue, proposed updated patch by priteau: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/925893 * "neutron-tempest-plugin-designate-scenario-zed" job failing - https://bugs.launchpad.net/neutron/+bug/2110550 Needed to pin the tempest plugin to zed-last, fix by ralonsoh merged: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/949643 Medium * occasional functional test failure: neutron.tests.functional.privileged.agent.linux.test_utils.FindListenPidsNamespaceTestCase.test_find_listen_pids_namespace - https://bugs.launchpad.net/neutron/+bug/2110878 CI failure but seen once in gate for now * ovs-agent: Leftover tpi/spi interfaces after VM boot/delete with trunk port(s) - https://bugs.launchpad.net/neutron/+bug/2095152 Trunk ports leftover for ML2/OVS following a change for ML2/OVN, see bug for details (reproducer) Patch proposed by rubasov: https://review.opendev.org/c/openstack/neutron/+/949217 -- Bernard Cafarelli

1 0

[openstack-helm] Are there any real users of the umbrella chart?
by Vladimir Kozhukalov 17 May '25

17 May '25

Hi team, This is to start the discussion about the future of the Openstack super (umbrella) chart [1]. My personal impression (maybe I am wrong) is that this chart is of extremely little interest. We continue to maintain this code (and spend testing resources) but maybe there are no real users of it. The chart deploys a compute-kit scheme but the same result can be achieved if one deploys multiple separate charts one-by-one. It seems convenient to have this single super chart that deploys Openstack with a single command, but IMO even small operators prefer using separate charts. Having said that, I would suggest removing this chart if it is not needed. [1] https://opendev.org/openstack/openstack-helm/src/branch/master/openstack -- Best regards, Kozhukalov Vladimir

3 4

[nova] Auto-convergence but for I/O
by Winicius Allan 16 May '25

16 May '25

Is there any option for disk I/O auto-convergence like conf.libvirt.live_migration_permit_auto_converg for memory-intensive instances? The use case is for an I/O intensive VM, so the disk cannot be migrated. Instead, it is necessary to change the max IO with `$ virsh blkdeviotune` then, migrate the instance and replace the current value with the old using the same command. regards.

2 1

[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